一开始定好规则
修改范围可控
修改范围需要与需求一致，如果修改范围扩大，会造成变更不可控，是极为危险的。需要有其他改动，需要在开始写代码之前就和CR的人协商一致后再进行。

以尽量小的单元提交
尽量一个功能完成就提交。为什么要这样呢？因为一次提交的代码太多了。从code review者的角度来讲：看代码的时候很可能联系不起来到底是出于什么功能修改的，一些问题可能会被漏掉。降低code review的质量。从开发者的角度来讲，一次开发考虑太多的东西，很可能每个都没有考虑细致到位。思路相对也没有那么清晰。在写代码被打断的时候，可能会中断其中一点的思考，一些要改进的漏掉了。相对是危险的操作。

CodeReview中最突出的问题
真正的问题没有发现，纠结的问题与开发者无法达成共识
有的同学做CodeReview的时候，依赖的是差异对比工具，往往只看到改了什么，但没有对工程深刻的理解，也没有实际把代码放到IDE中追踪修改方法被调用的地方涉及到几处，可能修改范围被扩大了，没有发现。发现的只是一些可维护性方面的问题，通常是一些代码坏味道。

这些问题非常重要，但带着这些问题上线不一定会引起真正的线上问题。但是修改范围扩大造成的影响可能会产生预想不到的问题。也有很重要的一点：代码坏味道的问题，往往仁者见仁，就像zookeeper建议部署单数个节点一样，两个人不容易协商出共识。谁妥协得多了，都会造成影响力方面的损失。

如果被CR的同学说着急上线怎么办
这要分情况。如果被CR同学的代码问题修改范围小，比如都是新增的代码，对其他人没有影响。同时确实老板说了要1个小时内上线。综合评估可以放宽要求。

但是这是极其例外的情况。一般同学说的着急其实也没有那么着急。比如第二天一早要提交。那头一天晚上到了下班点6点半还有问题。可以不要求在公司，回到家也可以打开电脑改改之后再提交一版，高质量让代码更不容易腐坏。

CR占用自己太多时间怎么办？
在排期的时候需要自己预留出这部分时间。如果在项目中承担的是项目组长的角色，在分配任务时可以将CR等管理工作计入工作量，开发任务给别人多分一些。如果是合作同事的角色，也可以将CR时间专门列出，在排期中专门留出并在日报、周报等汇报时体现。

终极大招
找领导或者团队架构师商量裁定。