在编程领域，编写易维护代码是很重要的一部分，不然就会出现「屎山雕花」的情况。以下是我关于编写「易维护代码」的一些心得。
易维护的代码有怎样的特性？
易调式
- 出现问题后，可以快速定位问题出现的原因。
易调整
- 可以方便地找到改动处，以实现需求或修复 Bug。
- 改动带来的影响面明确且可控。（如果出现「字符串依赖」，而相关的 package 又都是二进制就会很麻烦）。
易测试
- 容易写测试。
- 容易执行测试。
- 测试可以覆盖大部分代码和场景。
易理解
- 通过看模块/方法/变量名/注释就能大概知道内容。
- 统一的代码风格。
写出容易维护的代码需要考虑哪些因素？
做好封装
- 明确哪些数据和能力是可被外部获取的，哪些应该是内部处理的（
.h/.m）。 - 提供的能力是否有高关联度（高内聚）。
- 在做好封装的基础上，可以进行模块化开发，通过接口或协议来通信，将变化封装在模块内。
- 比较难的一点是模块的划分，一个技巧是将经常会联动改变的模块合为一个。
处理好状态
- 是否有必要新增一个状态，可否组合已有状态。
- 状态之间的切换是否清晰（状态多且复杂，可考虑用一个 Library 来管理）。
命好名
- 是否直观。
- 是否只做一件事。
- 不好理解的部分做好注释（为什么会有这段代码，它是怎么工作的）。
写好日志
- 出现问题时，可以通过日志快速定位。
- 处理好 Error 日志，尤其是当 Error 在多个模块之间传递时。
一些 code smell（不好的迹象）
- 方法体很长。（不方便复用和测试）
- 方法的参数很多。（不好理解和使用，也可能是没抽象好）
- 重复的代码。（多处出现了同样/类似的代码）
- 一个小的改动会涉及到多个文件。（可能没封装好）
- God Object。（很多不相关的内容聚合到了一起）
- 紧耦合。（比如明明只需要一个 Plain Object，却在参数里要求传入一个特定的 class instance）
- 通过一些 trick，依赖了 class 的内部实现。
一些技巧
- 精读 1 - 2 个优秀的有足够复杂度的开源项目。
- 重构项目，直到它具备了足够好的易维护性。