程序员必备的代码审查（Code Review）清单

本文由  伯乐在线 -  Lingfeng Ai 翻译， 进林 校稿。未经许可，禁止转载！
英文出处： fogcreek。欢迎加入 翻译小组。

在咱们关于高效代码审查的博文中，咱们建议使用一个检查清单。在代码审查中，检查清单是一个很是好的工具——它们保证了审查能够在你的团队中始终如一的进行。它们也是一种保证常见问题可以被发现并被解决的便利方式。

软件工程学院的研究代表，程序员们会犯15-20种常见的错误。因此，经过把这些错误加入到检查清单当中，你能够确保不论何时，只要这些错误发生了，你就能发现它们，而且能够帮助你杜绝这些错误。

为了帮助你开始建立一个清单，这里列出了一些典型的内容：

代码审查清单

常规项

• 代码可以工做么？它有没有实现预期的功能，逻辑是否正确等。
• 全部的代码是否简单易懂？
• 代码符合你所遵循的编程规范么？这一般包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
• 是否存在多余的或是重复的代码？
• 代码是否尽量的模块化了？
• 是否有能够被替换的全局变量？
• 是否有被注释掉的代码？
• 循环是否设置了长度和正确的终止条件？
• 是否有能够被库函数替代的代码？
• 是否有能够删除的日志或调试代码？

安全

• 全部的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）而且进行了编码？
• 在哪里使用了第三方工具，返回的错误是否被捕获？
• 输出的值是否进行了检查而且编码？
• 无效的参数值是否可以处理？

文档

• 是否有注释，而且描述了代码的意图？
• 全部的函数都有注释吗？
• 对很是规行为和边界状况处理是否有描述？
• 第三方库的使用和函数是否有文档？
• 数据结构和计量单位是否进行了解释？
• 是否有未完成的代码？若是是的话，是否是应该移除，或者用合适的标记进行标记好比‘TODO’？

测试

• 代码是否能够测试？好比，不要添加太多的或是隐藏的依赖关系，不可以初始化对象，测试框架可使用方法等。
• 是否存在测试，它们是否能够被理解？好比，至少达到你满意的代码覆盖(code coverage)。
• 单元测试是否真正的测试了代码是否能够完成预期的功能？
• 是否检查了数组的“越界“错误？
• 是否有能够被已经存在的API所替代的测试代码？

你一样须要把特定语言中有可能引发错误的问题添加到清单中。

这个清单故意没有详尽的列出全部可能会发生的错误。你不但愿你的清单是这样的，太长了以致于历来没人会去用它。仅仅包含常见的问题会比较好。

优化你的清单

把使用清单做为你的起点，针对特定的使用案例，你须要对其进行优化。一个比较棒的方式就是让你的团队记录下那些在代码审查过程当中临时发现的问题，有了这些数据，你就可以肯定你的团队常犯的错误，而后你就能够量身定制一个审查清单。确保你删除了那些没有出现过的错误。（你也能够保留那些出现几率很小，可是很是关键的项目，好比安全相关的问题）。

获得承认而且保持更新

基本规则是，清单上的任何条目都必须明确，并且，若是可能的话，对于一些条目你能够对其进行二元断定。这样能够防止判断的不一致。和你的团队分享这份清单而且让他们认同你清单的内容是个好主意。一样的，要按期检查你的清单，以确保各条目仍然是有意义的。

有了一个好的清单，能够提升你在代码审查过程当中发现的缺陷个数。这能够帮助你提升代码标准，避免质量良莠不齐的代码审查。

关于做者： Lingfeng Ai