共计 2745 个字符，预计需要花费 7 分钟才能阅读完成。
原创：猿天地（微信公众号 ID：cxytiandi），欢送分享，转载请保留出处。
CodeReview 我置信目前很多公司都会有这么一个流程，要害是这个流程有没有用就很难讲。次要还是取决于你对 CR 的了解以及有没有真正的去落地 CR，去器重 CR 带来的暗藏价值点。
正好最近也是有人在问我 CR 相干的问题，他们也要开始做 CR 了，想理解下有没有最佳实际之类的。所以明天跟大家聊聊 CR 这个话题，我说的也不肯定都是对的，仅供参考哈。
其实说实话，我感觉 CR 不存在什么最佳实际。因为每个公司或者说每个团队所进行的形式都会不一样，真正的想要做好 CR 只能先去做，在研发流程中去落地这个事件，而后缓缓的去提炼出合乎你们团队的 CR 形式。
1.CR 的目标
既然要做 CR 那必定就有起因，CR 的目标到底是什么？能够是走个流程，能够是进步代码能力，也能够是大家都在做，我也要做。我认为的目标有上面几个，请往下看。
1.1 稳固生产
大家想想，每个迭代开发实现后会进行测试，测试实现后就要公布到生产了。那么最有可能呈现的问题就是你的新性能外面可能改到了老的逻辑，假如测试没有回归进去这个问题。那么一上线这个就影响到了生产的稳定性，所以 CR 最重要的目标就是稳固生产。
咱们须要对代码进行 CR，看看有没有改到老代码，会不会影响老的逻辑，有没有加开关呀，有没有兜底动作呀。因为一个团队外面总归会有新人进来，在不是很熟悉业务的状况下，很有可能就会改错，很有可能就会留下一个潜藏的 Bug，这些都是须要 CR 去重点关注的。
上线能够，相对不能影响到老版本，相对不能出故障，否则你的绩效就凉凉了。你说你不想做 CR，你的共事们会容许么，小伙子还是乖乖做 CR 吧！
1.2 间接造就 backup
在治理团队的时候肯定要留神造就 backup，因为你也不晓得下一个来到团队的人会是谁。互联网公司流动性还是挺大的，因为只有跳槽能力涨工资呀，我又说出了大家的心里话。
除了在明面上，能够指定谁作为某一块业务的 owner，开发的时候由 owner 带着其余的人一起进行开发，这个过程中其实就有了 backup，因为这一块业务晓得的不在是某一个人了。
在台面下也要留神造就 backup，此时 CR 就是一个很好的机会。CR 的时候就能够让更多的人相熟这些业务，然而形式肯定要留神，不要赤裸裸的只看代码，这样没参加开发的必定是一个很懵的状态。能够在 CR 前让大家先大略的看下 PRD，而后让 CR 的人解说的时候不是一行行代码去 Review, 先要讲本人这个迭代做的什么需要，有哪些性能，对应的代码就是当初 CR 的代码。这样能力让大家即理解业务又做了 CR，一举两得。
当然，此时你会说，就算依照你说的形式进行 CR，也不肯定其他人就很相熟了呀！这个是当然的，最相熟的还是写代码的那个人嘛！然而咱们让其他人有了一个大略的印象，如果前面写代码的那个人到职了，当有 Bug 要修的时候，其他人也是有映象过后这个性能的代码在哪里，我还记得 CR 过，我还提了一些倡议。总比啥都不晓得要强吧，你说对么？
1.3 进步代码品质
单纯从技术层面登程，CR 的目标就是让大家来找茬，挑刺的。每个人的教训都不同，每个人的思路也不一样，往往你感觉这样写是最简略的形式，他人可能有更简略的形式去实现。
在 CR 的过程中，大家会提出本人的认识，实现的思路，代码是否写的够简洁，是否有开源框架可能间接实现某个性能，是否是否用设计模式进行优化，进步扩展性。领域建模是否正当，模块划分是否到位等等一系列的问题。
对于新人来说，可能失去很多有教训的共事在 CR 时给出的倡议，对他的成长是很有帮忙的。而且也会让你们的我的项目代码的品质始终维持在一个高的程度。这就是咱们要做 CR 的目标，当然事实往往可能很残暴，很多我的项目到最初都会比拟乱，代码也很臃肿，我想可能是过后被业务方倒排期，赶着要上线导致的吧！这种状况很常见，特地在守业型公司。
2.CR 的形式
后面讲了几点我认为 CR 的目标，那么如何进行 CR 呢？常见的形式有哪些，来，接着往下看。
2.1 Gitlab
应用 Gitlab 做 CR 之前个别都是先提一个 MR 申请，而后针对这个申请做 CR。这个 MR 申请外面所有的变动就是咱们须要 CR 的点，如果有什么须要批改的能够在对应的代码处减少备注，CR 完结之后各自依据过后的备注去批改。
2.2 开发工具
在咱们的开发工具中间接进行 CR 也是十分的不便，益处在于能够看到整个性能的所有代码，就是你能够跟着业务的流程去解说对应的代码。而后也能够很分明的比照出哪些是你本人的改变，哪些是老的代码。
3.CR 的机会
3.1 提测之前
在提测之前是最好的 CR 机会，这个时候咱们有须要改良的再 CR 之后就间接改掉了。而后提测的时候就曾经是咱们改过之后的代码了，兴许就缩小了很多 Bug，测起来也如丝般顺滑。
提测之前就 CR 影响的是什么？是咱们的开发工夫，原本开发实现之后就马上提测的，然而要在提测前进行 CR，除非你的开发进度提前，否则还没开发完怎么做 CR?
这个其实就是咱们下面讲的流程了，将 CR 融入到研发流程中去，这样就能够在评估工夫的时候给 CR 留出一天的 buffer，比方 11 号要提测，那么 10 号就 CR, 9 号就是开发实现。
3.2 提测之后
提测之后做 CR 其实很不好，咱们之前也有这样做过，做完之后立马改成了提测之前。因为在做的过程中会提出一些须要批改的点，而后这些点有可能测试曾经测完了。而后你又改了，导致产生了新的 Bug，减少了测试的工作量。
甚至还有一次是 CR 时候当场改的，而后没留神间接提交了，也没跟测试同步。第二天发生产环境间接出 Bug 了，所以肯定不要在提测之后邻近上线之前进行 CR。
再举一个列子，之前有个团队老是喜爱在上线当天进行 CR，测试曾经再整体回归了，他们还在 CR。当然有没有改变代码我不太分明，因为不是一个团队，然而最重大的是回归的时候是有 Bug 的，须要及时修复。而后找不到人修，他们去 CR 了，也没人关注。导致的后果就是每次上线都要搞到好晚。
3.3 上线之后
上线之后就更不要 CR 了，你上线之后 CR 有什么意义呢？代码都公布了，这个时候 CR 进去的问题改还是不改呢？下个迭代改吗？下个迭代改完是不是又要回归一次，测试违心么？
正所谓今日事今日毕，以后迭代的事件就在以后迭代解决，否则就是堆积如山了。
总结
对于 CR 咱们还是要踊跃的拥抱，去落地，去实际。看上去会破费一部分工夫，但带来的收益还是很不错的。我的项目的代码品质进步了，团队的技术气氛变好了，线上 Bug 显著变少了，大家对业务更相熟了。
如果你们没有 CR，请把这篇文章刷给你老板，就是这么任性。
如果对你有用，来个转发呗！
对于作者 ：尹吉欢，简略的技术爱好者，《Spring Cloud 微服务 - 全栈技术与案例解析》,《Spring Cloud 微服务 入门 实战与进阶》作者, 公众号 猿天地 发起人。
