您如何处理对提高质量影响最大的遗留代码库？

当您在遗留代码库中工作时,随着时间的推移会产生哪些影响,从而提高代码库的质量？

删除未使用的代码

删除重复的代码

添加单元测试以改善覆盖率低的测试覆盖率

跨文件创建一致的格式

更新第三方软件

减少静态分析工具(即.Findbugs)生成的警告

代码库是由许多开发人员编写的,他们多年来具有不同的专业知识水平,许多领域未经测试,有些领域不可测试,而且没有花费大量时间编写测试.

阅读Michael Feather的书"与遗产代码有效合作"

这是一本很好的书.

如果你不喜欢这个答案,那么我能给出的最佳建议是:

首先,停止制作新的遗留代码[1]

[1]:遗留代码=没有单元测试的代码,因此是未知的

在没有自动化测试套件的情况下更改遗留代码是危险且不负责任的.如果没有良好的单元测试覆盖率,您无法知道这些更改会产生什么影响.Feathers建议采用"束缚"方法,在这种方法中,您需要更改需要更改的代码区域,编写一些基本测试以验证基本假设,通过单元测试进行小的更改,然后从那里开始计算.

注意:我并不是说你需要停止所有事情并花费数周时间为所有事情编写测试.恰恰相反,只需测试您需要测试和从那里进行测试的区域.

吉米·博加德和雷·休斯顿在一个非常类似的主题上做了一个有趣的屏幕演示:http: //www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/06/pablotv-eliminating-static-dependencies-screencast. ASPX

我使用由大约50名程序员编写和修改的遗留1M LOC应用程序.

* Remove unused code

几乎没用......只是忽略它.你不会从那个获得巨大的投资回报率(ROI).

* Remove duplicated code

实际上,当我修复一些东西时,我总是寻找重复的东西.如果我发现了一些我将一个泛型函数或注释所有代码出现重复(有时,放置泛型函数的努力不值得).主要的想法是,我讨厌不止一次做同样的动作.另一个原因是因为总会有人(可能是我)忘记检查其他事件......

* Add unit tests to improve test coverage where coverage is low

自动化单元测试很棒...但是如果你有大量积压,除非你有稳定性问题,否则任务本身很难推广.选择你正在研究的部分,并希望在几年内你能获得不错的报道.

* Create consistent formatting across files

IMO格式的差异是遗产的一部分.它会提示您编写代码的时间或时间.这可以为您提供一些关于如何在代码的这一部分中表现的线索.做重新格式化工作并不好玩,也不会给客户带来任何价值.

* Update 3rd party software

只有当新的操作系统不支持新的非常好的功能或您拥有的版本时,才能执行此操作.

* Reduce warnings generated by static analysis tools

值得的.有时警告可以隐藏潜在的错误.

添加单元测试以提高测试覆盖率.拥有良好的测试覆盖率将允许您无需担心地重构和改进功能.

CPPUnit的作者,有效地使用遗留代码编写了一本关于此的书.

对遗留代码添加测试比从头创建测试更具挑战性.我从这本书中摘取的最有用的概念是"接缝"的概念,Feathers定义为"接缝"

"你可以改变程序行为而不在那个地方进行编辑的地方."

有时它值得重构,以创建接缝,使未来的测试更容易(或者首先可能.)谷歌测试博客有几个有关该主题的有趣帖子,主要围绕依赖注入的过程.

我说'删除重复的代码'几乎意味着你必须将代码拉出并抽象它以便它可以在多个地方使用 - 理论上,这使得错误更容易修复,因为你只需要修复一段代码,与许多代码相对,修复其中的错误.