上周在处理业务代码的时候，涉及到一些非常老的代码，这些代码注释和提交日志都没有明确说明修改逻辑，所以在此基础上的修改可能会为后续的迭代带来质量隐患。
恰巧最近看到一篇讲注释重要性的文章，如果有兴趣可以看完整的内容。
Reduce technical debt by valuing comments as much as code
作者认为，注释是最有效的减少技术债的方式之一。
they lighten the workload of future programmers who will work on the code
这涉及到一个问题，代码是否会长期使用
- 不是业务是否会长期持续，因为不同的业务可能会复用同一块代码，比如公共库
- 不是“死代码”，因为有的代码虽然存在，但已经长期没有运行到或维护到
注释是如何削减技术债的呢？
- 解释代码目的 explain the code’s purpose
- 解释代码逻辑 explain the code
- 凸显潜在的坑 highlight the potential gotchas
- 标识后续的工作 provide landmarks for future work
注释能加速开发效率和维护效率，也避免了重复踩坑。
再分享一个我之前工作的案例。华为对代码质量也是出名的高，所有的修改必须要有明确的注释说明。
华为所有的修改，都来源于问题单，无论是需求、BUG、重构或者优化。每个问题单都会有一个单号，相应的代码修改必须要有begin end包围（哪怕只有一行代码），添加单号、修改人、修改日期。如果代码中不方便写完整的逻辑注释，就需要在问题单中补充。
当然，他们会有严格的提交审核制度。通过gerrit系统和加分机制，确保代码合入主干前经过了多人审核。
我们可以借鉴什么？
做系统和做应用有很大的不同。系统稳定性是最重要的，应用可以通过快速更新迭代快速修复问题。
多数公司内部都会有一套自研或者外部采购的流程系统，类似于华为的问题单系统。而我们多数情况下面对的问题是，要么记录不完整，要么记录与代码关联度较低。在必要的需求或问题描述之后。一个简单的动作就可以达成与代码的关联，比如在commit中添加需求链接或缺陷链接，这样也避免了由于修改文件过多或者代码分布过碎所徒增的注释成本。
