为什么单独的维护工作，从发展的工作？

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

我的第一份工作是维护一些软件模块，其原始开发者已经搬到一些新的项目。

我猜:

• 使得新的发展更可预测，更容易日程安排：因为开发商不被称它修理一些未知的-在-提前数量的修的问题

• 机会来训练新的开发(例如我)

此外，代码我是保持不是"垃圾"--它是电信软件、一个早期报交换网络，已经部署的客户，像钟等。它被设计得很好，写得很好，可以测试(套自动化测试的情况下)，容易维护，许多日志中的文件，有些设计文件...

...字幕来你运似乎是，"男人，这个代码很臭!我希望我能得到原始开发者，并擦 他的 鼻子： 那 要学他！"

所以当代码写得很好了，这个论点(教的原始开发者)不适用。

当我说我是做"维护"是一种像新特征的发展，但非常小的功能...例如，互操作与新客户设备的其解释的协议规格中的某些稍微不同寻常的方式。

[我会分析和诊断的问题，并编写一个修复;和一个QA人会增加新的相应试验的情况下自动化测试的套房。]

Answer 7

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

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