代码审查推进落地

  在推进新的代码审查规范落地，谈谈感想。

   代码审查本身的必要性其实不必多言，再优秀的程序员也会犯低级错误，代码审查就是在代码成果交付时由开发发起的一次QA。与测试不同，代码审查完全是透明的，所以在这个动作中就有更有效率问题发现和解除能力。在降低风险角度，代码审查等于在开发阶段引入双重保障，减小问题持续暴露到生产的概率。除去业务相关，额外收益是审查带来代码质量的提升，开发者有机会获得优秀的编码意见，从而引导更优雅的实现和自我提升。

   在推进新的审查规范前，原来嵌入研发流程本来是有一个审查规定，即git的master分支的merge权限只在部分有审查能力的员工，规定在发布前进行代码审查。这个流程尴尬点在于，在一般项目推进中，没有给CR分配工时，或者分配了工时在较紧张的开发过程中被挤压掉了，导致动作最终流于形式。

   所以，合理考虑流程与审查质量是强相关的。此外，规范的逻辑完整，实操性，推进层次的规划都是需要在考虑之中的，这些点不多作表述。

   审查内容。一个是代码规范，目前有sonar的平台的检查点，阿里开发手册，以及迄今为止的一些工程问题的汇总，作为参考。再加之必查的高频高风险检查清单。审查内容有时候不是问题，反而审查力度权衡是关键。

   审查过程。作为程序开发，总有一种误区觉得一定要是搭一个什么平台来做这个事情，但回归事情本身，其实做了这件事再去优化效率更重要。所以在推进初期，在规范框架下通过简单的文档和人肉的流程管理更具有灵活性。评审形式也在桌面和会议审查视规模和重要程度来确定。后期在跟踪过程中，支撑异步审查和远程审查的必要，才有规划进行平台的搭建。

    结果和跟踪。问题是不是问题，真的是要一刀切吗？目标和期望往往是完美的，但现实总是缺点意思，毕竟每个人的水平有差异，项目也有很多因素不一定要做到代码的完美。所以让问题留在规范里面更重要。在简单业务堆砌项目中，低风险的低质量代码在日程紧急的场景下上线的可能必须在规范里有所体现，即问题的分级。其优势在于可以构造跟踪能力在后续推进优化。