maintenance - 为什么要将维护工作与开发工作分开？

Question

我在一家公司工作，维护由同一个团队完成，为软件带来生命。

我经常听说组织有单独的维护团队或维护程序员。我想知道的是——这背后的原因是什么？

除了将“旧代码”丢给普通人之外，还有吗？

从维护自己的“垃圾”中吸取的教训具有更高的价值吗？由最初导致缺陷的人来修复缺陷不是更有效吗？

我是否遗漏了任何真正的理由来说明为什么拥有一个单独的维护团队可能是有益的？

Answer 1

想到最能描述这一点的概念是“捶打”。这本质上是与您进行维护工作和开发工作相关的转换成本。这可能是职责分离的最大原因。其他包括让初级或入门级程序员有机会涉足，并让您更有经验的开发人员生产更高价值的项目。

与此同时，我认为开发人员编写了一个必须支持它的应用程序是有一定价值的。首先，他们会很快在他们的代码中找到可以从中学习的问题。其次，他们会考虑代码的可维护性和质量，因为他们必须支持它。

现实生活中的颠簸示例：

您被分配了一个 1500 小时的开发项目，并且还负责系统维护和支持您最近的 3 个应用程序。在这个新项目中，你平均每周被打断 7 次来支持这 3 个应用程序。每次你开始处理其他 3 个应用程序时，你都会花 20 分钟来思考这个问题。解决问题后，您将花 20 分钟时间重新思考您上次在新应用中触及的代码。这是每次中断 40 分钟或每周 280 分钟的总成本。这意味着您在一周内仅切换到支持这些应用程序就损失了 2.67 小时的工作效率。

Answer 2

我已经在敏捷团队工作了一年多。我认为在实时产品的情况下并不重要（我的意思是客户只使用最新版本）。但是假设您在市场上有多个版本的产品，您必须支持每个版本。

以 Bentley 的 Microstation 为例。它是 3d 的设计应用程序（建筑、工厂设计、铁路公路桥梁等）。现在假设我们在市场上有 v8、v9、v10。它们具有不同的功能，并且文件格式在版本之间发生了显着变化。但是这些项目是如此巨大（或者客户端是如此重要），以至于您必须支持 v8 客户端和 v9 客户端，同时还要开发 v10 的东西。因此，公司有必要为以前的版本分配一个维护团队（或时间）。此外，如果您的产品支持定制和上述场景，通常这些团队称为定制团队。

Answer 3

我不会说我同意这种做法，但在许多组织中，简而言之，顾问被聘请来编写软件，然后匆忙努力，然后将项目交给内部程序员来“维护”。基本原理是，您可以聘请未经培训的技术更熟练的人，然后让他们将“知识转移”包括给那些致力于保持软件完整的人。

简而言之，大部分时间都是出于政治/不切实际的原因。

Answer 4

我猜这个问题更实际：

• 旧代码是由不再在公司或团队中的人编写的；
• 旧代码是由外部开发人员编写的；

在很多公司中，拥有一个不再由原始编码人员维护的代码库是很常见的，因为它们不再存在。如果代码库足够大，则必须有人对其进行更新，因此他们被称为维护者。

如果您可以避免这种情况，对您有好处，但请确保它始终是暂时的。

Answer 5

我认为拆分维护和功能开发团队的动机是为了让事情顺利进行：如果功能开发团队一直不得不停止他们正在做的事情来处理错误修复，那么项目就会停滞不前。拥有一个单独的维护团队可以让其他开发人员腾出时间来保持有问题的项目/产品向前发展。

Answer 6

我的第一份工作是维护一些软件模块，它们的原始开发人员已经转移到一些新项目。

我正在猜测：

• 使新开发更可预测，更容易安排：因为开发人员不会被取消它来修复一些预先未知的维护问题

• 培训新开发人员的机会（例如我）

此外，我维护的代码不是“垃圾”——它是电信软件，一种早期的分组交换网络，已经部署给 Bell 等客户。它设计精良、编写精良、可测试（自动化套件测试用例），可维护，大量日志文件，一些设计文档......

...您的 OP 的副标题似乎是，“伙计，这段代码很臭！我希望我能找到原始开发人员，然后摸摸他的鼻子：那会学习他的！”

因此，当代码已经编写好时，该论点（教原始开发人员）不适用。

当我说我在做“维护”时，有点像新功能开发，但功能非常小……例如，与新客户设备互操作，这些设备以某种不寻常的方式解释协议规范。

[我会分析和诊断问题，并编写修复程序；并且 QA 人员会在自动化测试套件中添加一个新的相应测试用例。]

Answer 7

我可以看到的一个优势是，组织中至少还有一个人负责充分理解代码以修复它。此外，如果他参与设计/开发审查（他/她应该这样做），此人将有不同的议程，并且可以从维护的角度审查代码。

此外，“维护”可能是指一系列活动，例如部署、配置、备份等，这些活动绝对应该由不同的团队处理。