在日常的研发工作中，CodeReview（以下简写为CR）是代码交付的一个重要环节，通过CR可以提前发现代码潜在风险与BUG，提升系统的可维护性，降低事故的概率及修复成本。长期来看CR促进了团队内部知识共享，提高团队整体水平。
CR过程对于研发人员来说，也是一种思路重构的过程，也可以帮助更多的人理解系统。研发人员的时间有限的，CR过程是一个研发人员自我要求较高的事情。
作为CR的发起人，需要想清楚，希望谁来进行自己提交的代码的Review，如何更高效发现代码中潜在的风险。
而作为CR的评审人，也是需要想清楚，为什么需要你来Review这次代码的提交，你的Review是否可以帮助发现潜在的风险，降低线上事故的概率。
研发人呗是最清楚代码的变动的，特别是基础架构优化的过程，大部分的代码变动是对于已有的代码的重构。涉及到现有的代码的更改会涉及到多个业务，而并不是所有业务都熟悉的这个人在作架构的优化的研发。这时代码的提交，就是需要各个业务相关方一起发现潜在的风险。
那么如何组织CR呢？重点有5条
- 代码提交的研发人员准备代码变动依据，可以提前准备相关的文档，如技术方案，需求，相关的协议等。
- 需要邀请业务相关方一起进进代码的的Review，如不确定业务相关方，或找不到当时负责的同学，那应该找相关的高工协调人员。
- 邀请QA同学一同进行CR，这样可以另外的视角发现更多的问题，QA同学也可以根据CR过程的进行测试的细节安排。
- 讲解代码变化的思路，分别找对应的业务方确认，如涉及到某个业务方的变化，这块需要单独提示一下业务方的同学，确认业务方的同学是在Review的状态。
- 每个业务方代表需要确认代码的修改是认同的，最终才是有效的。
CR的时间投入产出是一个概率问题，不能有侥幸的心理。功能上线之后在线上不出事故，并不能说明CR环节就一定是完全有效，CR是质量保证的基线。但是当在线上出现了事故，CR是否有效，是可复盘的。区别在于，质量问题的时间投入在早期，主动发现问题，把问题在研发阶段解决，还是把时间投入到后期，被动的发现问题，问题在线上阶段解决。
而作为研发人员，或参与CR人员，对于当次Review的代码，至少需要进行以下几个维度进行代码的Review，提前发现代码质量问题。我把他以规范原则的形式，进行了总结。
- 能力规范原则：代码实现的能力是否符合业务需要，代码是否进行必要的容错，代码是否对核心指标产生影响影响，完成所需的能力是根本。
- 编码规范原则：公司或团队统一的编码规范，每个语言都有不同，是否有一些违规的写法，代码是否易读，代码注释健全，与团队代码风格是否纺一。
- 流程规范原则：如研发流程代码提交的规范，如Commit log，版本号设定，分支拉取，代码合并方式等。
- 工程规范原则：整体的代码是否符合产品线的工程规范，如命名规范，目录划分，资源划分，模块划分，功能可复用及对已有的功能复用等等。
- 设计规范原则：整体的方案是否存达过度设计/设计不足的情况，设计思路是否清晰，设计原则是否应用的得当。这部分的工作在方案的评审时可以发现相关问题，但是CR的过程也同样需要再次Review，避免实施过程，出现偏差。
- 扩展规范原则：代码是否容易扩展，当前代码支持的业务是否存在增加功能的情况，当新增功能时是否容易实现。
- 测试规范原则：代码是否覆盖了正常的场景及异常的场景，逻辑分支是否覆盖完整，当出现bug时测试人员是否容易发现，是否有debug工具及日志输出的支持等。
- 维护规范原则：代码是否足够简单，逻辑是否容易理解，使用的技术是否通用，业务的修改成本等。
- 能力规范原则：代码实现的能力是否符合业务需要，代码是否进行必要的容错，代码是在对核心指标产生影响影响。
- 安全规范原则：安全规范常见的如，通讯数据安全，本地数据安全，用户隐私保护，线程安全等等
- 接口规范原则：接口变更是否合规，影响面及相关依赖方的适配是否完成，接口是否存在隐式的调用，接口是否需要对外公开等等
总结来说，代码的CR重点关注代码的有效性，可读性，可扩展性，可维护性，可复用性及可测试性等等，CR是研发人员把代码提测前的最后一个环节，在这个节点之前产生的为质量保证所有的行为，都算是主动的行为，而一但以修复bug的方式解决质量问题，这个过程就取决于发现的bug数据，客观的讲，基于bug质量的保证过程是有点被动。测试只能确认已经测试过的路径是否存在风险，而对于线上真实的用户使用场景，的确存在非预期内的组合，而对于研发人员来讲，能作的是尽可能的提前发现潜在的风险，CR就是一个较好的方法。
