宝,我今天CR了,C的什么R? 走过场的CR

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微服务 入门 实战与进阶》作者, 公众号猿天地发起人。

上一篇:文本或代码中 \n 和 \r 的区别


下一篇:iOS开发融云即时通讯集成详细步骤