Evolution principles of software development

你可以从本文了解到

本文是对《软件设计的 201 个原则》的第9章——软件开发的演变原则的学习

演变是与修改软件产品相关的一系列工作，用于：

1. 满足新功能

2. 更有效地运行

3. 正常运行（当检测到原始产品中的错误时）

185 软件会持续变化

任何正在使用的大型软件系统都将经历不断的变化，因为系统的使用会使人想出新的功能。

它会一直变化，直到从头开始重写变得更划算。这就是曼尼·雷曼（Manny Lehman）的“持续变化定律”（Law of Continuing Change）。

186 软件的熵增加

任何经历持续变化的软件系统都会变得越来越复杂，并且变得越来越杂乱无章。

由于所使用的所有软件系统都会发生变化（原则 185），并且变化会导致不稳定，因此所有有用的软件系统都将朝着较低的可靠性和可维护性迁移。这就是曼尼·雷曼（Manny Lehman）的“熵增加定律”。

187 如果没有坏就不要修理它

假设你在维护一个系统。你正在检查组件的源代码。你可能是想增强它，或者是想找到错误的原因。

在检查时，你觉得自己发现了另外一个错误。不要试图“修复”它。很有可能你会引入而不是修复一个错误（原则 190）。

相反，应记录并提交变更请求。期望通过配置控制和相关的技术评审来确定它是否是一个错误，以及应该以什么样的优先级进行修复。（原则 175，177，178 和 179）

188 解决问题，而不是症状

当软件出错时，你的责任是彻底理解错误的原因，而不只是草草分析一下，并对你认为的原因进行一个快速的修复。

189 先变更需求

如果各方都同意对软件进行增强，那么第一件事就是更新软件需求规格说明（SRS: Software Requirements Specification），并获得批准。

190 发布之前的错误也会在发布后出现

发布之前错误就比较多的组件，发布之后也会发现比较多的错误。这对开发者来说是个令人失望的消息，但确实是被经验数据所充分支持的（而且由原则 114 可知，你在一个组件中发现的错误越多，将来也会发现更多）。

最好的建议是废弃、替换、从头创建任何具有不良历史记录的组件。不要花钱填坑。

191 一个程序越老，维护起来就越困难

在对软件系统进行更改（无论是维修还是增强）时，系统中必定有一些组件要被修改。

随着程序变“老”，每次改动时，整个系统中需要修改的组件的比例也会随之增加。

每次更改都会使所有后续的更改更加困难，因为程序的结构必然会恶化。

192 语言影响可维护性

倾向于强制高内聚和低耦合（原则 73）的语言，例如 Eiffel，通常有助于开发和后续维护。级别很低的语言（如汇编语言）通常会在开发和维护期间抑制开发效率。可对照查看原则 99。

193 有时重新开始会更好

如今关于重建（reengineering）、翻新（renovation）和逆向工程（reverse engineering）的讨论太多了，我们可能都开始相信这样做很容易。

这很难做。有时这很有意义，值得投资。

其它时候这是对珍稀资源的浪费，从头开始设计和编码可能是更好的选择。

举例来说，扪心自问，如果你制作了设计文档，维护者们真的会使用它们吗？

194 首先翻新最差的

原则 193 建议，重新开始有时可能是最好的主意。另一个不那么痛苦的方法是，完全重新设计和重新编码“最差”的组件。

这里“最差”的组件是指那些消耗了最多改正性维护费用的组件。

Gerald Weinberg 报告说，在一个系统中重写一个 800 行的模块（占全部改正性维护成本的 30%），就可以为整体维护工作节省大量的资源。

195 维护阶段比开发阶段产生的错误更多

维护期间对程序的修改（无论是改进功能还是修正缺陷）引入的错误远远超过最初的开发阶段。维护团队报告说，维护期间有 20％ 到 50％ 的改动会引入更多错误。

出于这个原因，遵守“规则”是如此重要：制定 SCM 计划（原则 174），控制基准（原则 179），并且不要绕过变更控制（原则 182）。

196 每次变更后都要进行回归测试

197 “变更很容易”的想法，会使变更更容易出错

为了避免这种情况，要确保你正在做的变更是经过核准的（原则 182 及 183 ），对每项变更进行核查（原则 97），并在每组变更后进行回归测试（原则 196）。

198 对非结构化代码进行结构化改造，并不一定会使它更好

相反的，你应该采用合理的软件工程原则，重新考虑模块，并从头开始重新设计。

199 在优化前先进行性能分析

当需要优化程序以使其更快时，请记住 80% 的CPU周期将被 20% 的代码消耗（Pareto定律）。

因此，先去找到那些能够带来优化效果的 20% 的代码。

最好的方法是使用任何市场上可买到的可用的性能分析工具。

性能分析工具在你的程序运行过程中监控它，并识别出“热点”，也就是消耗最多 CPU 周期的部分。优化这部分。

200 保持熟悉

这就是 Manny Lehman 的“熟悉守恒定律”（Law of Conservation of Familiarity）。

软件修改的时间越长，开发人员对它的“感觉”就越陌生。

总结：保持产品发布版本之间的改动量相对稳定。

201 系统的存在促进了演变

系统引入到它要解决的问题的环境中，本身就改变了这个环境，也就会引发新的问题。

无论你认为自己多完美地实现了需求，都必须为部署之后必要的变更做好计划。