“为什么本该在90分钟内完成的心脏急救检查，成功率不到50%？为什么会有高达2/3的死刑判决发生了错判？我们到底能掌控多少？又有哪些事根本不在我们的可控范围内？
或许，我们犯错，是因为没有掌握相关的知识；或许，我们犯错，不是因为没有掌握相关的知识，而是没有正确使用这些知识。人类的错误分为两大类型，“无知之错”，可以原谅；“无能之错”，不被原谅。”
- 《清单革命》
通常在项目中，代码评审是不可或缺的一个环节，很多时候代码质量在某种程度上也就是被这种机制所守护。
多数的团队困惑不在于做不做代码评审，而是我们需要什么样的大神来做代码评审呢？
就像感慨每一个公司都希望有一个乔布斯来设计产品一样，每一个团队都希望有一个Guido van Rossum（Python之父）或者James Gosling（Java之父）来帮忙评审代码。
只是，我们真的是如此的无知么？
在这个知识付费遍地跑，Google资料一大把的年代，知识对我们来说不是太少，而是太多。
本着精简主义原则，先让我们来聊聊 代码评审中不该做的事儿。
What Not To Do
设计
代码评审是审查现有代码并从中学习的过程， 而不是讨论设计思想的时间或地点。如果想到设计思路，请将它们分开写下来，并在代码审查之外进行讨论。
编写代码
如果您正在编写任何代码，则不会进行评审。唯一的例外是注释中的两行代码短行，以帮助传达缺陷或建议的修复。
批判
代码评审是团队中的每个人在改进代码的同时学习和编写更好的代码的机会。我们都犯错误，我们都有机会学习。代码中的缺陷是每个人学习和改进的机会。
To Do
代码评审检查清单
1935年的时候，波音公司研制的B－17型轰炸机，在进行试飞过程中发生了爆炸。针对这个巨大的缺陷，波音公司不是大幅度改进了这个型号飞机的机械系统，而是将飞机的起飞、巡航、着陆、滑行等各个阶段的重要步骤浓缩到一张卡片上，飞行员会根据清单的提示检查刹车是否松开、分析仪表是否准确设定、机舱门窗是否完全关闭，还有升降舵能控制版面是否已经解锁？
在飞行手册上，正常的检查清单不过3页，剩下的200多页都是针对异常情况的检查项。当异常发生时，飞行员能够依据清单来化解危机。
你的清单中可以包含，但不仅限于以下的内容：
-
可维护性
- 代码有意义吗？
- 在执行代码审查之前，请努力了解代码应该执行的操作。
- 要求开发人员尽可能多地发表评论以使代码可读。
错误处理
1.代码是否符合公认的异常处理约定。
2.代码是否只是捕获异常并记录它们？安全
资源泄漏
控制结构
可重用性
etc
可以的话，你也能拥有那么长长的checklist，只是要记得依据你们团队的情况去定期更新它。
如何持续、正确、安全地把事情做好，这正是清单工具的魅力所在。
所以，你准备好你们组的代码评审的清单革命了么？
