如何更新大型遗留代码库以满足特定的质量标准？

关于用于改进遗留代码库的工具和技术的信息很多，但是我还没有遇到任何成功的现实案例研究。大多数建议都是微观的，尽管很有帮助，但由于缺乏证据，因此无法说服很多人，因为它不能在宏观上提供帮助。

我正在专门寻找渐进式改进，这些改进已被证明在更新大型遗留代码库以满足当今的质量标准而不是完全重写时在现实世界中是成功的。

之前：

• 大：大于1MLOC
• 旧版：无自动化测试
• 劣质：高复杂度，高耦合，高逸出缺陷

后

• 自动化测试
• 更容易的更新/维护
• 高质量：降低复杂度，解耦代码，避免一些缺陷

在现实世界中，已经证明了哪种增量步骤可以成功更新大型遗留代码库，以达到上述质量标准，而无需进行完全重写？

如果可能，请在回答中包含一个示例公司或一个大型旧项目的案例研究，该项目已通过“成功的”质量改进过程以进行备份。

像http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052之类的书应该足以见证该行业中常见的大型，传统劣质代码库。

我的猜测是，为什么您没有听说过，更重要的是，直到您亲自研究其中的一个之后，您才可能不太可能听到他们的信息，是，似乎没有人出于各种原因能够说清楚他们的代码以上是所有这些的基础，没有遇到不小的影响。

这可以解释您所说的研究不足。如果您读了足够多的书，例如Peter van der Linden的Deep C Secrets，您将读到大约一百万美元的bug，其中缺少哪个项目的bug。

注意：我想对此发表评论，但时间太长。我了解这不能完全回答问题。

编辑：C ++ 11＆GCC的长期生存能力受到质疑 -如果开发人员重构GCC并使其更像LLVM / clang工具，它可能提供了一个很好的例子。讨论指出，某些地方的文档不多，从而使新开发人员的入门门槛更高。

2013年2月3日，LibreOffice开发人员之一迈克尔·米克斯（Michael Meeks）在几天之内发表了题为“ LibreOffice：清理和重构巨大的代码库，或者为什么重写它甚至会更糟的演讲”。 。” 听起来确实像是您要的东西：讨论他们为获得“一个不好理解的，巨大的代码库”所做的讨论，该代码库用德语进行了广泛评论，没有任何单元测试，复杂的构建基础结构以及25个年未付的技术债务”并使之现代化。

演示文稿可以在线流式传输，并且（我认为）录制文件将在将来的某个日期提供。

实际上，我在职业生涯中经历了三次重大的重构。代码有衰减的趋势，因此，如果您的代码库足够长，那么就不可避免地需要进行大量重构。我所有的示例都基于私有代码，这可以解释为什么很难找到公共示例。

第一次，是一个相信或不相信的应用程序，其基本架构使其只能与点矩阵打印机一起使用。当我的公司找不到供应商来供应色带时，他们指派我让它与激光打印机一起使用。

第二次是将数百个自动化测试脚本从C迁移到Java，部分原因是我们需要更好的跨平台功能，另一方面是因为雇用新的C开发人员变得越来越困难。

我第三次仍在中间，这是将一个庞大的单片应用程序模块化，从而通过减少耦合以及跨平台的目的来进行单元测试。

我把努力比作爬山。您面前有这个宏伟的目标，但您不能在宏观层面上解决它。您一次握住一个手柄，始终处于关闭的后备位置，直到下一个安全装置到位之前，才可以断开前一个安全装置的连接。您开始只是进行一些小小的增量改进，然后转了一会儿，突然看到了美丽的景色。

举例来说，假设您有60,000个高度耦合的代码文件。您想开始将其置于单元测试下，但是依赖项使其无法实现。您如何解决？您解耦一个文件。您添加自动测试。在继续前进之前，您需要回到稳定的地面。重复59,999次。

如果听起来很简单，那是因为它很简单。这并不容易，但是很简单。起初很难注意到任何进展。我们距离似乎不可能进行的重构已经两年了，可能要等到我们完成之前还有很多年，但是回首过去，我们突然意识到代码已经变得更好了，并且我们能够继续提供新功能同时给我们的客户。

其他两次以相同的方式工作。您找到了可以采取的最小安全步骤，并且采取了这一步骤，始终将应用程序保持在工作状态。您只需要担心全局，以确保您朝着正确的方向前进。您的所有操作都是小规模，稳定且递增的。

根据在数百万行代码库上的个人经验，我发现了一些可行的策略。

查看所有错误（甚至是已关闭的错误），并尝试将其分解为几类。专门尝试按它们所属的组件对其进行分解。如果它们属于多个组件，请注意它们确实属于。完成此操作后，将查看哪个存储桶最大，然后使用该存储桶确定从哪里开始。此外，您可以查看文件的修订历史记录以确定哪些更改最大，并将其用作从何处开始的指南。基本上，您要尝试的是找到最破损的修复程序并重复进行。另外，我发现尝试同时修复所有问题永远无法解决，只会导致更多问题。

如果发现很多东西属于多个组件，则表明存在“系统”问题，并且可能表明代码耦合太紧密或需要刷新的API。

我花了很多时间的另一个领域是测试现有的代码库。这里有多种策略，各有千秋，但没有一个是解决问题的完整方法。

• 单元测试可以工作，但是由于紧密耦合的代码，很多时候您只能进行单元测试。但是，请尽您所能。
• 外部测试是另一种途径。我认为您可能已经拥有了，如果没有，我会花一些时间来创建它。另外，对我有用的是增加将故障/事件随机注入系统的功能。除此之外，尝试同时注入多个事物以尝试使其以新方式失败。