看到一篇同行评审的文章,感受不错,特转载。ide
原文连接: http://www.ibm.com/developerworks/cn/rational/11-proven-practices-for-peer-review/工具
主要观点以下:开发
- 一次评审少于 200–400 行的代码。
- 目标为每小时低于 300–500 LOC 的检查速率。
- 花足够的时间进行正确缓慢的评审,可是不要超过 60–90 分钟。
- 肯定代码开发者在评审开始以前就已经注释了源代码。
- 为代码评审和获取制度创建可定量化的目标,这样您才能改进流程。
- 使用检查列表,由于它能够极大地改进代码开发者和评审者的做品。
- 确认缺陷确实获得修复了。
- 培养良好的代码评审文化氛围,在这样的氛围中搜索缺陷被看作是积极的活动。
- 警戒“老大”效应。
- 最少评审一部分代码,就是您不能评审所有的代码,以从 Ego Effect 中受益。
- 采用轻量级,能用工具支持的代码评审。