代码审查清单可消除更多的bug

在关于高效代码审查的博客中，咱们推荐使用清单(checklist)。清单是代码审查中的伟大工具——他们确保审查在团队里持续高效。它们也是确保常见问题被识别、解决的方便途径。

   软件工程协会的研究代表，程序员常犯的错误有15-20种。所以把这种错误增长到清单里，你就能确保在它们出现时指出来，帮助消除这种隐患。

   

   为了让你开始创建清单，下面是经典的条目列表：

代码审查清单

整体

• 代码能运行吗？代码实现了想要实现的功能了吗，逻辑是正确的吗，等等。

• 全部代码都很容易理解吗？

• 它遵循了大家都赞成的代码规范吗？规范一般包括花括号的位置、变量和函数的命名、行长度、缩进、格式和注释。

• 有多余的或重复的代码？

• 代码尽量模块化了？

• 全局变量能被替换？

• 有任何被注释掉的代码？

• 循环结构里有固定的长度值和正确的结束条件？

• 有代码能够被类库函数取代？

• 日志和调试代码能够被移除？

安全

• 全部数据输入都被校验(为了正确的类型、长度、格式和范围)和转码了？

• 第三方工具集在哪里用到了，可以返回被捕捉到的错误吗？

• 输出值通过校验和转码了？

• 不合法的参数值获得处理了？

文档

• 有文档吗，文档描述了代码意图吗？

• 全部的函数都加注释了？

• 任何不寻常的行为和边界处理都作说明了？

• 就第三方类库的使用和功能写文档了？

• 全部的数据结构和测试单元都作解释了？

• 有不完整的代码？若是有，它应该被移除仍是打上’TODO‘之类的适当标记？

测试

• 代码可测试吗？好比，不要增长太多的或隐藏的依赖，不可以实例化对象，测试框架可以使用方法等。

• 有测试吗，它们全面吗？好比，至少包含了大家承认的代码覆盖率吗？

• 单元测试实际地测试了代码正在实现的目标功能了？

• 数组检查’越界‘错误了？

• 测试代码可被已有API的应用取代吗？

   你还能够为清单增长一些语言相关的问题。

   该清单故意没有包含全部的问题，你并不想一个长长的清单，以至于没人去使用。只需覆盖常见问题便可。

优化你的清单

   把该清单作为一个起点，你应该针对具体用例进行优化。有个不错的办法，那就是让你的团队在代码审核时，花一点时间提出所产生的问题。有了这些数据，你就可以甄别出团队的常见错误，而后就被改形成常见清单。要确保删除那些不会发生的条目(你或许但愿保持较少地发生，还有诸如安全相关的重要条目)。

集思广益，及时更新

   作为通用法则，清单上的条目应该是具体的，若是有可能，你能够就此作一份二元决策【注1】。这有助于避免判断上的矛盾，与团队分享清单，并获得他们对于内容的认同也是不错的主意。确保按期审查清单，检查每一项以确保仍然相关。

   有了优秀的清单武装，你就能够增长代码审核中的瑕疵数量。这有助于你提高代码质量、避免不稳定的代码审核质量。

   为了更多地了解Fog Creek上的代码审核，请观看下面的视频：http://fast.wistia.net/embed/iframe/vigy79tuhq

• 注1：A binary decision is one that can have only two outcomes. Binary decisions are basic to many fields. http://en.wikipedia.org/wiki/Binary_decision 。关于二元决策图，请参考：http://zh.wikipedia.org/wiki/%E4%BA%8C%E5%85%83%E5%86%B3%E7%AD%96%E5%9B%BE

   原文地址(source)：http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/