协作编程指南： Insepction

背景

今天读到《代码大全》第21章 Collaborative Construction（协同构建）的时候，对其中推荐的方法Inspection感触颇深。基本上所有的公司都会制定代码规范要求程序员遵守，但是还是有很多团队的代码质量惨不忍睹，为什么？因为规范没有被落实。为什么没被落实？因为没有监督。很多国内的公司都是单个人负责一个项目，甚至连简单的peer review都没有就可以合并代码，最终导致代码质量越来越差甚至不可控。即便团队内有经验丰富，代码风格良好的程序员，也没能影响到全队的代码质量。

Inspection

理想的情况下，每个人写出的代码都应该得到全队的review，所有人一起保证合并到线上的代码是完全遵守代码规范的（或者有充足的理由不遵守）。但是这样太耗时了。书中推荐了一种更佳的实践，只在定期举行Insepction，在控制时间的情况下，我觉得能很好的保证代码质量。我做如下简化描述。

一， 人数： 3-6 人
二， 角色： 1主持人， 1作者， 1-4 评论员
三， 时间： 1小时。保证速度和效率
四， 流程

1. 主持人从本周的PR里面随机挑选一个
2. 作者花费 1min描述PR的背景和内容（不需要对业务背景作详细介绍，主要描述自己做了什么）
3. 所有人花费5min review PR 并且comment（comment主要针对代码风格， 比如变量和函数名，循环嵌套，重复啰嗦等等）
4. 讨论comment并记录解决方案， 10 -15min。会上只解决简单的代码风格的问题，对于业务逻辑和解决方案（design）设计的问题只记录不解决，由疑问者和作者线下继续讨论。下一次会议再同步结果。

Review 一个 PR 的总时长控制在半小时以内，一次会议至少review 2个PR。由于时长的限制，还可以鼓励作者提交短小精悍的PR（不包括模板代码，自动生成的代码和测试代码，有效代码行数在200以内）