标签：
在《浪潮之巅》中，吴军老师描述了Google早期的工作方式，有一部分这样说：我一般会在吃完晚饭后把代码修改的清单发给克雷格做代码审核，他一般晚上10点左右会回复我，给我修改意见，详细到某一行多了一个空格。而这个内容，实际就是软件开发过程中的同行评审的流程。
自然，在我们平时做的一些小的project中，我们提交项目之前互相测试寻找bug也是一定意义上小的Peer Review。
[目的]
延伸到实际的软件项目操作过程，在正规软件管理过程中，同行评审是对错误进行控制的一种非常有效的方法。会有以下一些很好的效果：
可以很好的解决在方法、逻辑、实现上的作用；
确保该产品贴切需求
让manager可以很好的了解掌控整个产品的质量
交流不同的方法
从别人的视角而不仅仅是作者来support或者modify产品
在讨论中很容易发现当前的opportunity
有利于及时的发现并且解决issue.
[范围]
而Peer Review的对象不仅仅是刚才说到的代码和上课我们讨论的产品规格书，它贯穿于整个软件工程开发阶段：
Should we do this project? (需求阶段)
产品需求说明书等
Can we do this project?（计划阶段）
系统方案、项目计划等
Are we doing this project?（开发阶段）
详细设计、单元测试方案、集成测试方案、代码、数据库脚本。
尤其是在编码之前要详细的设计评审。
Did we do this Project?（验证阶段）
系统测试方案
其实总结来说：就是我们要对所有可能有potential defects的所有important project进行评审
[实施方法]
[人员角色]
Author:
工作的原作者；
在会议中回答别人提出的关于这个产品的问题；
不可以作为Moderator, Reader, Recorder
Moderator:
计划这个inspection meeting的人
掌控整个meeting
最后Reports inspection results to Peer Review Coordinator
Reader:
负责展示这个Product给其他inspectors
Recorder:
分类和记录在meeting中大家提出的issue
Inspector:
发现缺陷的人
严格来说－会议中的所有人都是inspector
标签：
原文地址：http://www.cnblogs.com/RabbitHole/p/4419874.html
