为什么要进行代码评审？

作者 | Kaiden 爱数AnyBackup数据库保护研发部-研发总监

目录

什么是技术债务？

技术债务的表象和消除手段

引入代码评审机制

评审对象

评审维度

评审流程

改进计划

对于代码评审的思考

代码评审是一项持续性工作

关注问题转为关注能力—提升团队的可持续性

---

什么是技术债务？

Ward Cunningham（沃德·坎宁安）在1992年首次提出：交付第一次代码就像陷入债务。 债务是可以加快开发速度，只有通过重写代码，及时偿还债务。如果不偿还债务，就会发生危险。 把时间花在写一些不正确的代码上的每一分钟都算作该债务的利息。 整个软件项目可能在未合并代码的部署，面向对象设计或其他方面的债务问题而陷入停顿。

同时，卡内基-梅隆大学软件工程研究所（SEI）的Robert Nord在《The Future of Managing Technical Debt》提出了“技术债务全景图”（Tech Debt Landscape）的概念。

技术债务全景图主要从两个方向来分析技术债对于软件系统的影响：可维护性（Maintainability）、可演进性（Evolvability），同时结合问题的可见性（Visibility）分析技术债务对于软件开发过程的影响。

2011 年 3 月 25 日Gartner发布Gartner-CAST 白皮书：货币化技术债务，有如下描述：

技术债务的表象和消除手段

基于以上的信息，相信大家会对技术债务有足够的的认识，那么我们思考以下几个问题：技术债务的载体是什么？技术债务具体的体现是什么？

程序的最初原型是代码，那么技术债务的载体也应该是代码。对于代码中的一些坏味道，就是我们所说的债务，具体体现在以下几个方面：

1. 不能均匀分布的复杂性。
2. 重复代码。
3. 不合适的注释。
4. 违反代码规范。
5. 没有单元测试。
6. 缺陷和潜在的缺陷。
7. 设计和系统架构受限与当时的条件。

这些点带来的问题也就显而易见了，会导致：额外的研发成本；不稳定的产品质量；难以维护的产品。