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