程序员需要知道的软件维护规范 重构时机 如何重构 重构后的测试

软件维护规范

1. 软件的熵

• 熵是一个来自物理学的概念，指的是某个系统中的“无序”的总量。当软件中的无序增长时，程序员们称之为“软件腐烂"(software rot)。

1.1 破窗户

• 一扇破窗户，只要有那么一段时间不修理，就会渐渐给建筑的居民带来一种废弃感——职权部门不关心这座建筑的感觉。于是又一扇窗户破了，人们开始乱扔垃圾。出现了乱涂乱画，严重的结构损坏开始了。
• 一扇破窗户 —— 一段设计低劣的代码、团队必须在整个项目开发过程中加以忍受的一项糟糕的管理决策——就足以使项目开始衰败。如果你发现自己在有好些破窗户的项目里工作，会很容易产生这样的想法：“这些代码的其余部分也是垃圾，我只要照着做就行了”。
• 按照同样的道理，如果你发现你所在团队和项目的代码十分漂亮一编写整洁、设计良好，并且很优雅，就很可能会格外注意不去把它弄脏。
• 不要留着“破窗户＂（低劣的设计，错误决策、或是糟糕的代码）不修，发现一个就修一个。

2. 重构

• 随着程序的演化，我们有必要重新思考早先的决策，并重写部分代码，这一过程非常自然。代码需要演化；它不是静态的事物。
• 重写、重做和重新架构代码合起来，称为重构 (refactoring)。

2.1 你应在何时进行重构

• 当你遇到绊脚石——代码不再合适，你注意到有两样东西其实应该合并或是其他任何对你来说是＂错误＂的东西——不要对改动犹豫不决。应该现在就做。无论代码具有下面的哪些特征，你都应该考虑重构代码：
  • 重复。你发现了对 DRY 原则的违反。
  • 非正交的设计。你发现有些代码或设计可以变得更为正交。
  • 过时的知识。事情变了，需求转移了，你对问题的了解加深了。代码需要跟上这些变化。
  • 性能，为改善性能，你须要把功能从系统的一个区域移到另一个区域。
• 时间压力常常被用作不进行重构的借口。但这个借口并不成立：现在没能进行重构，沿途修正问题将需要投入多得多的时间一那时将需要考虑更多的依赖关系。
• 用一个医学上的比喻来解释重构：把需要重构的代码当作是一种“肿瘤＂，切除它需要进行“侵入性”的外科手术。你可以现在手术，趁它还小把它取出来。你也可以等它增大并扩散——但那时再切除它就会更昂贵、更危险。等得再久一点，“病人”就有可能会丧命。
• 遵循早重构，常重构的原则。
• 追踪需要重构的事物，如果你不能立刻重构某样东西，就一定要把它列入计划，确保受到影响的代码的使用者知道该代码将被重构，以及这可能会怎样影响他们。

2.2 怎样进行重构

• 就其核心而言，重构就是重新设计，团队任何人设计的任何东西都可以根据新的事实、更深的理解、变化的需求等等，重新进行设计。
• 怎样进行利大于弊的重构：
  • 不要试图在重构的同时增加功能。
  • 在开始重构之前，确保你拥有良好的测试，尽可能经常运行这些测试。这样，如果你的改动破坏了任何东西，你就能很快知道。
  • 采取短小、深思熟虑的步骤，重构常常涉及到进行许多局部改动，继而产生更大规模的改动。如果你使你的步骤保持短小，并在每个步骤之后进行测试，你将能够避免长时间的调试。
• 当你看到不怎么合理的代码时，既要修正它，也要修正依赖于它的每样东西，要管理痛苦：如果它现在有损害，但以后的损害会更大，你最好一劳永逸地修正它。

2.3 重构后的测试

• 重构后应通过测试以及valgrind的测试。

3. BUG

• BUG修复由模块开发者或者维护者完成。
• 发现 bug 则说明 bug 漏过了现有测试网，需要在测试中增加新的测试。
• 及时修正发现的 bug。
• 修正后应通过测试以及valgrind的测试。