一个长期运行的生产系统，总是处于修改和扩展之中。要提高运维质量，就不得不关注可修改性（modifiability）。
什么是可修改性？书中的定义是：修改系统的难易程度，以及系统适应这些修改的灵活程度。这里所谓的难易程度，灵活程度都是较为主观的评价，可能每个人的标准都不一样。但在维护一个老旧的或僵化的系统，大家的感受和抱怨都是相通的。
那么具备可修改性的系统都有什么特征呢？什么因素会影响系统的可修改性呢？
- 系统的设计
- 模块化
- 遵循SOLID原则、设计模式，将系统实现成封装良好、职责清晰、文档齐全的模块。
- 使用面向对象的设计方法，利用封装、继承、多态等技术开发代码，实现业务功能。
- 高内聚，低耦合（Cohesion & Coupling）
- 内聚（Cohesion），指的是模块承担的各种职责之间的紧密程度。如果一个模块，没有核心功能或职责，或者各项职责之间的关联性不大，则其内聚程度不高。比如在MVC架构下，程序员常常把一个大的特性的实现代码都塞到一个类中，没有依据功能拆分类，这就是典型的没有内聚的反模式。
- 耦合（Coupling），指的是模块之间的相关或依赖程度。如果两个模块之间总是互相调用，则耦合程度较高。紧耦合并不是好的设计，会降低系统的可修改性。我们修改一个模块，其他模块往往也需要关联修改。另外作者认为单向依赖可能影响不大，需要重点关注双向依赖。
- 书中提供了一个简单的度量公式：
内聚性 = 模块内相关的方法数量 / 模块内所有方法的数量 * 100 A模块到B模块的耦合性 = A模块内依赖于B模块的方法数 / A模块内所有方法的数量 * 100
- 模块化
- 代码可读性
- 什么是可读性？程序的逻辑被理解和遵循的程度。
- 这个我们都有体会，好的代码，都是逻辑简洁清晰、有良好注释、遵循语言惯用法、遵守编码风格的代码，看起来舒服，理解起来没难度。最讨厌故弄玄虚，炫技和没有重点的啰嗦。
- 可读性的反例：
- 面条式的代码，没有设计，没有组织，没有结构和控制流程，看起来像流水账。
- 泥球，上帝类，屎山。。。毫无设计的堆砌、缝合在一起的代码。
- 拷贝粘贴，没有抽象和复用，管杀不管埋，没有丝毫责任心。
- 缺少注释
- 代码风格不统一
作者提供了一些提升可修改性的方法。这些方法问ChatGPT或者Bard，都能给你整一箩筐出来，关键是落地难，现在程序员流动性大，大家只管眼前，关注进度而不是质量，导致随处可见的烂代码。天理循环，最后大家维护的都是烂代码。
- 采用静态检查，发现代码风格和质量问题，以及坏味道。
- 坏味道，有类、方法、变量等层次的坏味道。
- 持续的重构代码
- 设计高内聚、低耦合的模块
