1、项目组人数少，比如某个模块由一个人开发，怎么查？
---建立研发中心级的现场检查机制。 这个模块人不多，但可以邀请他所属的开发小组进行现场检查。 例如，他可以用C，邀请其他C成员进行现场检查。 不一定需要本项目的人参加现场检查。
2、查问题记录不方便。 有使用方便的调查工具吗？
---我们的代码由Git管理，并且与Gerrit集成得很好。 Gerrit是一个行走调查工具，可以设置在将代码提交给Git时必须行走调查。 也可以保存步行调查记录
---网上也有很多免费查插件的事情。 图省事的话，可以在【错误】等需要修正的代码中记录特殊的标记
3、查实发现的许多问题都很规范，对代码质量贡献不大
---走查必须用工具进行静态扫描，待扫描面问题解决后进行查码。 否则，两者的工作会重复。 Java建议使用checkstyle，findbugs，c建议使用CPPlint，cppcheck
4、开发时间本来就少，再加上去查代码，时间太长了
---代码进度调查的作用不需要说明。 建议在规定的时间进行。 团队一旦习惯，自然会成为团队日常工作的一部分。 建议安排在每天下午17336000----17336030，分流30次解决进行调查中发现的问题
---如果有确定紧急故障的同事的反馈，或者有其他紧急情况，可以申请延期这次调查活动，或者不参加
5、审核同事对代码不熟悉，无法发现问题。
---漫游检查活动不仅要确认功能是否实现，还需要确认代码和设计是否一致。 测试用例完整有效吗？
---有助于知识共享，打破技能障碍，同时开发学生解释自己