编者按：
7月12日，weibo上 @自律自强 发表了一条微博：十几年来的软件项目经历告诉我，评审是最有效也是成本最低的质量保证和提升的手段，设计书和代码100%肉眼全覆盖绝对值得，而且还是迅速提高新人能力及其成果物的规范性的有效手段。
各路朋友纷纷参与讨论，各有观点，真知灼见也许就在其中，读来很有收益。所以汇总得本文。
@自律则强 十几年来的软件项目经历告诉我，评审是最有效也是成本最低的质量保证和提升的手段，设计书和代码100%肉眼全覆盖绝对值得，而且还是迅速提高新人能力及其成果物的规范性的有效手段。
BG4DUK：同感！但同样蕴含着巨大的风险即无产出。其背后原因是仅仅依赖人。好的办法是行程review的办法，步骤等等，同时不断汇总评估review的质量，才能真正做好
liangjz：目前实践看输出一般，对人依赖重
女皇碎碎：评审耗时多，规则的定义也比较难。。。没结果前，领导都不愿抽出多余的人力，时力做这
至简李云：对于评审的实施，发自内心地改变意识是关键，不然效果一定不好。
自律则强：意识不改变，在资源的投入上就会缩手缩脚；只有把评审做到位，才能体会到评审活动的高效，初级团队那种走马观花式的“评审”，是浪费时间，不是真正的评审。到位地完成评审后，会有那种对系统质量“踏实了”的感觉，之后辅以严密的变更管理，系统质量就不会出大问题
自律则强：归根到底，系统质量是要靠上游工程做出来的，依赖下游工程(种种测试)来把质量关，不仅低效而且昂贵。
高阿达：质量保证需要让上游可以时刻俯瞰下游的每一个细节。
jackywgw：确实如此，不过能坚持认真评审下来的公司和团队也确实不多
张克强-敏捷307：赞同。在多种评审形式中，双人同级互查是最经济的，性价比高，值得推荐
武剑锋：赞同。不过独立测试仍然有很高价值。再好的设计人员也有局限。
张克强-敏捷307：Yes，测试与评审不可互相替代。但最困难的是多数团队不相信100%覆盖的代码评审能够带来正收益，所以不尝试。前期各项质量保证手段往往通过测试阶段的缩短来获得项目中的收益。
火星人陈勇：我最相信肉眼，肉眼看过感觉不舒服的代码，即使看不到直接的bug，也要改。
张克强-敏捷307：回复@火星人陈勇:赞！为了提高效率，我同样推荐代码检查工具，工具可以把不符合既定义规则的地方找出来。但工具不能替代人。 推荐工具先查，然后肉眼再看
李智勇SZ：回复@项目管理郭致星:现在我这边限制取得更大成果的主因素是：代码的熟悉程度与项目的有效时间。一旦跨领域代码量又大，人员对代码的理解就直接限制评审的深度。一旦时间逼的紧，评审的优先级往往会被降低。而留给评审的时间似乎总不够。各位那里什么状况?
张克强-敏捷307：看到的最大障碍：进度紧张，工作量有限，没时间搞代码评审。
PMO之道---蔡德辉：IT行业缺少质量保证手段，也缺少质量专家来进行研究与推广。评审是其中最有效的手段之一。测试本来是验证手段，现在变成了找Bug手段，所以IT行业质量成本在40%以上，这是巨大的浪费，但我们好像没找到啥好办法。
拯救与逍遥：最大的障碍是从来就不知道代码评审的好处，自然也就排不出时间
火星人陈勇：正在评测resharper，先用工具弄到零错误，再肉眼。
火星人陈勇：回复@朱少民:我们现在很重视工具的警告，要仔细看明白才能处理，也因此不让工具自动运行，要人做出判断。 //@朱少民:所以吗，工具作用也不可忽视，没必要肉眼100%
PMO之道---蔡德辉：回复@质量市场学:是应该总结出来IT项目质量保证方法，从策划开始保证质量。测试作为最后的手段，现在的研究把测试前移到开发前，这还不够。至少目前应该大力推广评审，接下来应在策划和设计阶段推广潜在失效分析等。现在不是方法多，而是少，并且没被掌握。所以就无所谓按照实际情况调整了。
蝈蝈俊：前期要有技术评审，后期要有Code Review。
袁斌_AgileDo：Bug是代码注入的，如果在写代码之前和写代码过程中消除bug的风险，则会减轻评审的压力
自律则强：有经验数据显示，代码完成后，即使程序员经验丰富，每KLOC中也会注入12-16件Bug,有效地评审应该摘出大约2/3(7-10件)，而且使程序有良好的结构
pkuxkxjason：相当赞同。不过我不赞同“评审”这个词，英文code review比较准确。这是一个大家一起来读代码，通过头脑风暴，早期检出问题的过程。不是评，更不是审。有很多code review搞成了参会人员指点江山，代码作者极力自卫。在我做code view的经历中，几乎每次都能检出重大问题，而且对形成优良代码结构有益。
Glen-Wang：评审是社会化活动 1. 威慑被评审者 2.评审者学习
张克强-敏捷307：宝信软件伍治平和我早在n年前写过一篇论文，强调高频次小增量全覆盖的代码评审是代码评审的好实践。
王忠杰rainy：代码评审和自动测试要配合起来。
Bluebell--半失业中：貌似国内喜欢搞成过堂，我们是每段代码提交前都必须code review,reviewer 可以由自己邀请对这块比较熟悉的其他开发人员，一个人通过就行，当然将来这段代码出问题了，reviewer 也要担责。
pkuxkxjason：不使用。code review主要流程由开发者先介绍需求和针对需求的设计与实现。其他人针对需求review代码。 //@守候_盛开:请问使用checklist么？
stephen_wang_7971：我还是坚持：度量千行代码bug率不仅没有正面意义，反而误导开发人员把质量做的更差。因为其公式定义决定了：要是没有办法减少bug那就增加代码行数。而增加行数会引入新的bug。度量密度是为了减少密度，结果却增加了密度。
lvxinke：有人会故意把代码写得裹脚布。我的观点，可以度量作为参考，但不能作为考量，影响程序猿的职业心智。
lvxinke：我想说的，工具、统计都不是问题，关键是这些数据用来干什么。 //@自律则强: 在有统计意义的样式空间中，有些发生几乎是从然的，这是科学不是巫术。
自律则强：我更喜欢做的是，通读所有代码，把其中的错误和认为不是好程序的地方指出来，如：变量和方法的命名是否准确，是否有注释的作用，对内存使用是否粗暴无礼，程序结构是否思路顺畅，自然美观等等。然后再比对数据，它就在那里，没有太多刻意。
Jack_孙长虹：看度量为谁所用，如果开发者用来自我评估和改进，还是很有价值的。
hackersoul：评审本身就要浪费大量时间和人力成本，有时候有问题也不一定是bug，效率或者冲突什么的更烦人
刘东流：认同，在项目初期有效审查代码保证了后期开发的规范。逐行审查代码很多人认为麻烦，但为后期打下夯实基础。开始累点，让开发人员形成习惯，后期就轻松，并且还有质量保证。
__渔舟唱晚__：“引入阶段”是确实存在的：例如有制造缺陷的汽车可以返修，而有设计缺陷的汽车则必须召回。对用户而言是制造的问题，对厂商而言则是设计的问题。“引入阶段”的分析正是“明确责任，以图改进”。