本文已参与「新人创作礼」活动，一起开启掘金创作之路。
在日常的研发工作中，CodeReview（以下简写为CR）是代码交付的一个重要环节，通过CR可以提前发现代码潜在风险与BUG，提升系统的可维护性，降低事故的概率及修复成本。长期来看CR促进了团队内部知识共享，提高团队整体水平。
CR过程对于研发人员来说，也是一种思路重构的过程，也可以帮助更多的人理解系统。研发人员的时间有限的，CR过程是一个研发人员自我要求较高的事情。
作为CR的发起人，需要想清楚，希望谁来进行自己提交的代码的Review，如何更高效发现代码中潜在的风险。
而作为CR的评审人，也是需要想清楚，为什么需要你来Review这次代码的提交，你的Review是否可以帮助发现潜在的风险，降低线上事故的概率。
研发人员是最清楚代码的变动的，特别是基础架构优化的过程，大部分的代码变动是对于已有的代码的重构。涉及到现有的代码的更改也会涉及到多个业务，而并不是所有业务都熟悉的这个人在作架构的优化的研发。这时代码的提交，就是需要各个业务相关方一起发现潜在的风险。
那么如何组织CR呢？重点有5条
- 代码提交的研发人员准备代码变动依据，可以提前准备相关的文档，如技术方案，需求，相关的协议等。
- 需要邀请业务相关方一起进进代码的的Review，如不确定业务相关方，或找不到当时负责的同学，那应该找相关的高工协调人员。
- 邀请QA同学一同进行CR，这样可以另外的视角发现更多的问题，QA同学也可以根据CR过程的进行测试的细节安排。
- 讲解代码变化的思路，分别找对应的业务方确认，如涉及到某个业务方的变化，这块需要单独提示一下业务方的同学，确认业务方的同学是在Review的状态。
- 每个业务方代表需要确认代码的修改是认同的，最终才是有效的。
CR的时间投入产出是一个概率问题，不能有侥幸的心理。功能上线之后在线上不出事故，并不能说明CR环节就一定是完全有效，CR是质量保证的基线。但是当在线上出现了事故，CR是否有效，是可复盘的。区别在于，质量问题的时间投入在早期，主动发现问题，把问题在研发阶段解决，还是把时间投入到后期，被动的发现问题，问题在线上阶段解决。
