代码不朽

1 简介

1.1 什么是可维护性？

可维护性（一个系统可被修改的难易程度）是软件质量的一个特征，而性能（一个系统得到输出的速度快慢）是另一个特征。

软件维护的四种方式

1. 发现并修复Bug;
2. 系统需要去适应操作环境的改变；
3. 系统用户有新的需求，或者对之前的需求有变化；
4. 确定可以改进质量或者预防将来可能产生 Bug 的方法。

1.2 为什么可维护性很重要

1. 低可维护性会对业务造成严重影响
2. 可维护性是其他质量特征的推动者

1.3 本书的三个基本理论

1. 简单的原则最有助于提高可维护性；
2. 可维护性不是开发完才考虑的事情，每一个人的贡献都技术在内；
3. 各原则的影响大小不同。

1.3 对可维护性的误解

1. 误解：可维护性与使用的语言有关；
2. 误解：可维护性与行业有关；
3. 误解：可维护性等价于 Bug 的数量多少；
4. 误解：可维护性是一个“非此即彼”的是非问题。

1.4 评价可维护性

SIG 可维护性评级标准

评级	可维护性
5星	基准测试所有系统的前 5%
4星	基准测试所有系统的前 30%（高于平均水平）
3星	基准测试所有系统的前 30%（平均水平）
2星	基准测试所有系统的前 30%（低于平均水平）
1星	后5%可维护性最差的系统

SIG 可维护性评级内容

1. 代码库体积
2. 代码重复度
3. 代码单元大小
4. 代码单元复杂度
5. 代码单元接口长度
6. 模块耦合性
7. 组件平衡性
8. 组件独立性

1.5 可维护性原则的概述

1. 编写短小的代码单元
2. 编写简单的代码单元
3. 不写重复的代码
4. 保持代码单元的接口简单
5. 分离模块之间的关注点
6. 架构组件松耦合
7. 保持架构组件之间的平衡
8. 保持小规模代码库
9. 自动化开发部署和测试
10. 编写简洁的代码

2 编写短小的代码单元

1. 代码单元的长度应该限制在 15 行代码以内。
2. 不要编写超过 15 行代码的单元，或者将长的单元分解成多个更短的单元。
3. 提高可维护性的原因：短小的代码单元易于理解，分析及重用。

使用重构技巧来应用原则

1. 提取方法
2. 将方法替换为方法对象

3 编写简单的代码单元

1. 限制每个代码单元分支点的数量不超过4个。
2. 将复杂的代码单元拆分成多个简单的单元。
3. 提高可维护性的原因：分支点越少，代码单元越容易被修改和测试。

4 不写重复的代码

1. 不要复制代码。
2. 编写可重用的，通用的代码，并且/或者调用已有的代码。
3. 提高可维护性的原因：如果复制代码，就需要在多个地方修复 bug。重复代码更加难以分析和修改。

如何使用本原则：提取父类或通用模块。

5 保持代码单元的接口简单

1. 限制每个代码单元的参数不能超过 4 个。
2. 将多个参数提取成对象。
3. 提高可维护性的原因：较少的参数可以让代码单元更容易理解、重用和修改。

6 分离模块之间的关注点

1. 避免形成大型模块，以便能达到模块之间的松耦合。
2. 将不同的职责分给不同的模块，并且隐藏接口内部的实现细节。
3. 提高可维护性的原因：相比起紧耦合的代码库来说，对松耦合代码库的修改更容易监督和执行。

6.1 动机

1. 小型、松耦合的模块允许开发人员独立工作
2. 小型、松耦合的模块降低了浏览代码库的难度
3. 小型、松耦合的模块避免了让新人感到手足无措

6.2 如何使用本原则

1. 根据不同关注点拆分类
2. 隐藏接口背后的特定实现
3. 可以使用第三方库，框架来替换自定义代码

7 架构组件松耦合

1. 顶层组件之间应该做到松耦合。
2. 尽可能减少当前模块中需要暴露给（例如被调用）其他组件中模块的相关代码。
3. 提高可维护性的原因：独立的组件可以单独进行维护。

7.1 动机

1. 低组件依赖允许独立的维护
2. 低组件依赖可以分离维护职责
3. 低组件依赖让测试变得容易

8 保持架构组件之间的平衡

1. 平衡代码中顶层组件的数量和体积。
2. 保持源代码中组件的数量接近于9（6-12之间），并且这些组件的体积基本一致。
3. 提高可维护性的原因：平衡的组件可以帮助定位代码，并且允许独立对组件进行维护。

8.1 动机

1. 好的组件平衡能让查找和分析代码变得更加容易
2. 好的组件平衡能隔离维护所带来的影响
3. 好的组件平衡能分离维护职责

9 保持小规模代码库

1. 保持代码库规模尽可能小。
2. 控制代码库的增长，并主动减少系统的代码体积。
3. 提高可维护性的原因：拥有小型的代码，项目和团队是成功的一个因素。

如何使用本原则

1. 功能层面的方法
   1. 控制需求蔓延
   2. 功能标准化
2. 技术层面的方法
   1. 不要复制粘贴代码
   2. 重构已有代码
   3. 使用第三方库和框架

10 自动化开发部署和测试

1. 对你的代码进行自动化测试。
2. 通过使用测试框架来编写自动化测试。
3. 提高可维护性的原因：自动化测试让开发过程可预测并且能够降低风险。

10.1 动机

1. 自动化测试让测试可以重复。
2. 自动化测试会让开发更有效率。
3. 自动化测试让代码行为可预测。
4. 测试是对被测试代码的一种说明文档。
5. 编写测试能让你编写更好的代码。

10.2 如何使用本原则

1. 测试类型
   1. 单元测试
   2. 集成测试
   3. 端到端测试
   4. 回归测试
   5. 验收测试
2. 编写良好单元测试的基本原则
   1. 正常情况和特殊情况都要测试。
   2. 像维护非测试（生产）一样维护测试代码。
   3. 编写可独立的测试：它们的输出应该只反映被测试主体的行为。
3. 测量覆盖率来确定是否有足够的测试用例

11 编写简洁的代码

1. 编写简洁的代码。
2. 不应该在完成开发工作后留下代码坏味道。
3. 提高可维护性的原因：简洁的代码是可维护性的代码。

11.1 如何使用本原则

1. 不要编写单元级别的代码坏味道。
2. 不要编写不好得注释。
3. 不要注释代码。
4. 不要保留废弃代码：方法中无法到达的代码、无用的私有方法和注释过得代码。
5. 不要使用过长的标识符名称。
6. 不要使用魔术常量。
7. 不要使用未正确处理的异常。

12 后续事宜

1. 将原则变成实践
2. 底层级（代码单元）原则要优先于高层级（组件）原则
3. 对每次提交负责

---

Appendix

Copyright

CSDN：http://blog.csdn.net/y550918116j

GitHub：https://github.com/937447974