1.基本定义和说明
我们将一个软件系统可被修改的难易程度称为它的可维护性。
一个软件系统的可维护性由其源代码的多个属性决定。
可维护性（一个软件系统可被修改的难易程度）与性能（一个软件系统执行的时空开销，这里往往指得到输出的快慢）是软件质量的两个重要特征。（根据国际标准，软件质量可以划分为八个特征：可维护性、功能可适性、性能效率、兼容性、可使用性、可靠性、安全性、可移植性。）
2.软件维护的四种方式
- 纠正性维护：发现并修复Bug。
- 适应性维护：系统需要去适应操作环境的改变——例如，操作系统或者技术的升级。
- 完善性维护：系统用户（或者其他能够影响到系统的人，例如股东）有新的需求，或者对之前的需求有变化。
- 预防性维护：确定可以改进质量或者预防将来产生Bug的方法。
3.Why is important?
- 低可维护性会对业务造成严重影响。
- 可维护性是其他质量特征的推动者。
4. 十条指导性原则——可维护性软件概述
- 编写短小的代码单元。
短小的代码单元（方法和构造函数）更易于分析、测试和重用。 - 编写简单的代码单元。
拥有更少决策点的代码更易于分析和测试 - 不写重复代码。
任何时候都应该避免源代码重复使用，因为修改时就需要对每处代码进行修改。重复代码也是产生回归bug（regression bug）的一个来源。 - 保持代码单元的接口简单。
含有更少参数的代码单元（方法和构造函数）更易于测试和重用。 - 分离模块之间的关注点。
松耦合的模块（类）更易于修改，也利于构建模块化的系统。 - 架构组件松耦合。
系统顶层组件之间越是松耦合，越易于修改，也利于构建更加模块化的系统。 - 保持架构组件之间的平衡。
一个平衡度很好地架构拥有不多不少的组件、统一的代码规模以及最大程度的模块化，并通过有隔离关注点使得修改变得很容易。 - 保持小规模代码库。
大型系统之所以难以维护，是因为需要分析、修改并测试更多的代码。同样，大型系统中维护每一行代码的效率也比小型系统要低。 - 自动化开发部署和测试。
自动化测试（即测试不需要人工干预即可执行）可以得到对修改的有效性的及时反馈。手动测试难以形成规模。 - 编写简洁的代码。
代码库中存在越多的TODO、无用代码等遗留产物，新的团队成员就越难以高效工作，从而影响维护工作的效率。
5.可维护性的三条基本理论
- 坚持简单的原则最有助于提高可维护性。
- 可维护性不是开发完才去考虑的，而应该是在项目开发的一开始就加以考虑。每个人的贡献都应该计算在内。
- 对各个原则违背会带来不同的影响，有些严重程度甚于其他。一个软件系统越遵守原则，可维护性越高。
6.对可维护性的常见误解
- 可维护性与使用的语言有关。
- 可维护性与行业有关。
- 可维护性等价于Bug数量的多少。
- 可维护性是一个“非此即彼”的是非问题。
7.推荐阅读
- 《重构：改善既有的代码设计》
- 《代码整洁之道》
- 《代码质量》
- 《设计模式：可复用面向对象软件的基础》
