代码Review经常碰到的几个问题与应对方法

1、项目组人少，比如某个模块就一个人开发，如何做走查？
----建立研发中心级别的走查机制，这个模块人少，但是可以邀请他所属的开发组参与走查，比如他用的是C++，可以邀请其他C++成员参与走查，不一定要本项目的人才能走查。

2、走查问题记录不方便，是否有好用的走查工具？
----我们的代码是用Git管理的，与Gerrit很好的集成，Gerrit就是个走查工具，提交代码到Git时就可以设置必须走查，走查记录也可以保存下来
----网上也有很多免费的走查插件，如果图省事，可以在需要修改的代码上记录特殊标记，比如【BUG】

3、走查发现的很多问题都是规范性的，对代码质量没有太大帮助
----走查一定要先用工具做静态扫描，扫面的问题改完后才进行代码走查，否则两者工作重复。Java推荐checkstyle、findbugs，C++推荐CPPlint、cppcheck

4、开发的时间本来就不多，再加上代码走查，时间太紧张
----代码走查的作用没必要赘述，建议在固定时间举行，当团队养成习惯后，就会很自然成为团队日常工作的一部分，建议安排在每天下午17:00--17:30，流出半小时解决走查发现的问题
----如果有同事反馈正在定位紧急故障或有其它紧急事情，可以申请延缓或者不参加本次走查活动

5、评审的同事对代码不熟悉，发现不了问题。
----走查活动不仅仅要看功能是否实现了，还要看代码和设计是否一致？测试用例是否完备和有效？
----有利于知识共享，打破技能壁垒，同时开发同学通过讲解自己的代码，对个人沟通能力也是一种提升。特别是平时比较内向或者不太喜欢发言的同学。
----给大家提供一个每天交流、沟通的平台。工作一天也挺累的，是时候停下手中的编码工作，一起交流一下。

6、讨论发散或者纠缠在某个具体细节中，导致时间把控不好。
----设置主持人，一旦发现讨论发散、时间过长，主持人要及时喊停，把大家拉回到正确的节奏上。主持人最好由团队选举产生，可以是SM，也可以不是。

7、评审量大，只能走查部分代码，其他同事的内容没有覆盖。
----每个人介绍下要今天走查的内容和预计时间，优先走查自己认为风险较大的地方，尽量覆盖到每个人的代码。
----另外可以分小组并行进行，不一定要一个项目组聚集在一起

8、提问题的总是那几个人，其他人都是围观群众
----项目可以展示度量指标，比如走查发现问题数排行榜