本文探讨了代码评审的重要性，指出它在打破‘项目死亡’三角中起到的关键作用，防止烂代码的产生。文章揭示了代码评审的三个层次，强调其不仅是保证代码规范的手段，更是一种提升团队协作和文化建设的方式。通过提供高效代码评审的实践建议，如设定固定评审时间、保持客观态度和关注核心业务逻辑，促进团队成员间的知识传递和技术提升。
先来看一个令无数技术Leader闻风丧胆的项目“死亡”三角，业务压力引发代码质量下降，代码质量下降引发开发效率下降，开发效率下降又加重了业务压力，最终导致业务压力山大，乃至项目烂尾。如何破解？方法有很多，像精简业务需求、增加开发人手、升级技术架构等，很多时候需要多管齐下，但凡打掉这个“死亡”三角中的任何一角，就能终止这个恶性循环，甚至逆转为良性循环。
代码评审（Code Revew，简称CR）的首要打击目标显然是“烂代码”。避免“烂代码”的最好时机是写代码的时候，其次是代码评审的时候。IBM 的 Orbit 项目有 50 万行代码，使用了 11 级的代码检查（其中包含代码评审），结果是项目提前交付，并且只有通常预期错误的 1%。一份对 AT＆T 的一个 200 多人组织的研究报告显示，在引入代码评审后，生产率提高了 14％，缺陷减少了 90％。那到底什么是代码评审？如何进行代码评审？继续往下看。
1 CR 祛魅
我个人认为代码有这几种级别：1）可编译，2）可运行，3）可测试，4）可读，5）可维护，6）可重用。通过自动化测试的代码只能达到第3）级，而通过CODE REVIEW的代码少会在第4）级甚至更高。
—— 陈皓
下面 8 条有关 CR 的阐述，你觉得哪些是正确的？
- 搞形式主义，存粹是浪费时间
- CR 是保证程序正确性的手段
- CR 是保证代码规范的手段
- CR 是 Leader 的事，跟我没关系
- 我只看指给我的 CR，其他 CR 跟我没关系
- 没有时间 CR，直接 Merge
- CR 必须一行不落从头看到尾
- CR 必须一次完成
———————————————————————————————— 请仔细思考 60 秒
3…2…1…时间到，你的答案是几条？很抱歉，在我看来，没有一条是正确的。1、4、5、6 是送分题，显然都是错误的。7 是眉毛胡子一把抓，CR 就像读书，不是所有的书都适合精度，也不是所有的代码都需要评审。8 是任务心态，为了 CR 而 CR，CR 的目的不是完成 CR，而在于提升代码质量，你写代码时也不会一次完成所有功
最低0.47元/天 解锁文章
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
