关于易维护的代码

在编程领域，编写易维护代码是很重要的一部分，不然就会出现「屎山雕花」的情况。以下是我关于编写「易维护代码」的一些心得。

易维护的代码有怎样的特性？

易调式

• 出现问题后，可以快速定位问题出现的原因。

易调整

• 可以方便地找到改动处，以实现需求或修复 Bug。
• 改动带来的影响面明确且可控。（如果出现「字符串依赖」，而相关的 package 又都是二进制就会很麻烦）。

易测试

• 容易写测试。
• 容易执行测试。
• 测试可以覆盖大部分代码和场景。

易理解

• 通过看模块/方法/变量名/注释就能大概知道内容。
• 统一的代码风格。

写出容易维护的代码需要考虑哪些因素？

做好封装

• 明确哪些数据和能力是可被外部获取的，哪些应该是内部处理的（.h / .m）。
• 提供的能力是否有高关联度（高内聚）。
• 在做好封装的基础上，可以进行模块化开发，通过接口或协议来通信，将变化封装在模块内。
  • 比较难的一点是模块的划分，一个技巧是将经常会联动改变的模块合为一个。

处理好状态

• 是否有必要新增一个状态，可否组合已有状态。
• 状态之间的切换是否清晰（状态多且复杂，可考虑用一个 Library 来管理）。

命好名

• 是否直观。
• 是否只做一件事。
• 不好理解的部分做好注释（为什么会有这段代码，它是怎么工作的）。

写好日志

• 出现问题时，可以通过日志快速定位。
• 处理好 Error 日志，尤其是当 Error 在多个模块之间传递时。

一些 code smell（不好的迹象）

• 方法体很长。（不方便复用和测试）
• 方法的参数很多。（不好理解和使用，也可能是没抽象好）
• 重复的代码。（多处出现了同样/类似的代码）
• 一个小的改动会涉及到多个文件。（可能没封装好）
• God Object。（很多不相关的内容聚合到了一起）
• 紧耦合。（比如明明只需要一个 Plain Object，却在参数里要求传入一个特定的 class instance）
• 通过一些 trick，依赖了 class 的内部实现。

一些技巧

• 精读 1 - 2 个优秀的有足够复杂度的开源项目。
• 重构项目，直到它具备了足够好的易维护性。