代码评审赋魅

先来看一个令无数技术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 的阐述，你觉得哪些是正确的？

1. 搞形式主义，存粹是浪费时间
2. CR 是保证程序正确性的手段
3. CR 是保证代码规范的手段
4. CR 是 Leader 的事，跟我没关系
5. 我只看指给我的 CR，其他 CR 跟我没关系
6. 没有时间 CR，直接 Merge
7. CR 必须一行不落从头看到尾
8. CR 必须一次完成

———————————————————————————————— 请仔细思考 60 秒

3…2…1…时间到，你的答案是几条？很抱歉，在我看来，没有一条是正确的。1、4、5、6 是送分题，显然都是错误的。7 是眉毛胡子一把抓，CR 就像读书，不是所有的书都适合精度，也不是所有的代码都需要评审。8 是任务心态，为了 CR 而 CR，CR 的目的不是完成 CR，而在于提升代码质量，你写代码时也不会一次完成所有功