代码审查清单可消除更多的bug
在关于高效代码审查的博客中,我们推荐使用清单(checklist)。清单是代码审查中的伟大工具——他们确保审查在团队里持续高效。它们也是确保常见问题被识别、解决的方便途径。
软件工程协会的研究表明,程序员常犯的错误有15-20种。因此把这种错误增加到清单里,你就能确保在它们出现时指出来,帮助消除这种隐患。
为了让你开始建立清单,下面是经典的条目列表:
代码审查清单
总体
代码能运行吗?代码实现了想要实现的功能了吗,逻辑是正确的吗,等等。
所有代码都很容易理解吗?
它遵循了你们都同意的代码规范吗?规范通常包括花括号的位置、变量和函数的命名、行长度、缩进、格式和注释。
有多余的或重复的代码?
代码尽可能模块化了?
全局变量能被替换?
有任何被注释掉的代码?
循环结构里有固定的长度值和正确的结束条件?
有代码可以被类库函数取代?
日志和调试代码可以被移除?
所有数据输入都被校验(为了正确的类型、长度、格式和范围)和转码了?
第三方工具集在哪里用到了,能够返回被捕捉到的错误吗?
输出值经过校验和转码了?
不合法的参数值得到处理了?
有文档吗,文档描述了代码意图吗?
所有的函数都加注释了?
任何不寻常的行为和边界处理都做说明了?
就第三方类库的使用和功能写文档了?
所有的数据结构和测试单元都做解释了?
有不完整的代码?如果有,它应该被移除还是打上’TODO‘之类的适当标记?
代码可测试吗?比如,不要增加太多的或隐藏的依赖,不能够实例化对象,测试框架能够使用方法等。
有测试吗,它们全面吗?比如,至少包含了你们认可的代码覆盖率吗?
单元测试实际地测试了代码正在实现的目标功能了?
数组检查’越界‘错误了?
测试代码可被已有API的应用取代吗?
注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
安全
文档
测试
你还可以为清单增加一些语言相关的问题。
该清单故意没有包含所有的问题,你并不想一个长长的清单,以致于没人去使用。只需覆盖常见问题即可。
优化你的清单
把该清单做为一个起点,你应该针对具体用例进行优化。有个不错的办法,那就是让你的团队在代码审核时,花一点时间提出所产生的问题。有了这些数据,你就能够甄别出团队的常见错误,然后就被改造成常见清单。要确保删除那些不会发生的条目(你或许希望保持较少地发生,还有诸如安全相关的重要条目)。
集思广益,及时更新
做为通用法则,清单上的条目应该是具体的,如果有可能,你可以就此做一份二元决策【注1】。这有助于避免判断上的矛盾,与团队分享清单,并得到他们对于内容的认同也是不错的主意。确保定期审查清单,检查每一项以确保仍然相关。
有了优秀的清单武装,你就可以增加代码审核中的瑕疵数量。这有助于你提升代码质量、避免不稳定的代码审核质量。
为了更多地了解Fog Creek上的代码审核,请观看下面的视频:http://fast.wistia.net/embed/iframe/vigy79tuhq
原文地址(source):http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/
建议继续学习:
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:viviworld 来源: 腊八粥
- 标签: checklist 审查
- 发布时间:2015-01-23 23:45:47
- [70] Twitter/微博客的学习摘要
- [66] 如何拿下简短的域名
- [65] IOS安全–浅谈关于IOS加固的几种方法
- [64] find命令的一点注意事项
- [63] android 开发入门
- [63] Go Reflect 性能
- [61] 流程管理与用户研究
- [59] Oracle MTS模式下 进程地址与会话信
- [59] 图书馆的世界纪录
- [59] 读书笔记-壹百度:百度十年千倍的29条法则