什么是Code Review？要不要做Code Review？怎么做Code Review？

案例描述

随着Code Review一步步的开展，可能很多人同事在心里面会质疑在软件开发过程中竟然有这样的一个"鸡肋"，到底是不是"鸡肋"，本文从三个点来阐释我们究竟为什么要搞这一套，而且还搞了这么久！

 案例详解

什么是Code Review？

通俗的讲就是找出代码缺陷、功能实现问题、编码合理性、或者性能优化；直白一点就是检查代码，然后有事没事发一份代码检查邮件，当然现在大都是自动的检查；正因为现在Code Review已经纳入TM考核，所以现在不得不来科普一下。

要不要做Code Review？

要不要？我说了不算，这要看为什么要？

1. 及早发现潜在缺陷，降低修改/弥补缺陷的成本。

2. 促进团队内部知识共享，提高团队整体水平。

3. 评审过程对于评审人员来说，也是一种思路重构的过程。帮助更多的人理解系统。

4. 是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。

5. 鼓励程序员们相互学习对方的长处和优点。 

6. 可以被用来确认自己的设计和实现是一个清楚和简单的。

上面呢是一些比较官方的好的理解，下面我们来中肯的理解

1、为什么要做Code Review？因为我们是做技术的，代码写的好不好这就是技术水平的体现；

很多人认为Code Review只要出现在技术偏技术的团队就好了，业务型的团队Code Review做不做无所谓；

每次我拉出一大把代码问题提交给他们的时候，他们通常会给出这样的答复：

1）工作时间压得太紧，没时间搞，上线业务能用就没问题了 。

2）需求老变，版本迭代太快，代码本事生命周期就很短，今天写了下周就杠掉，烂就烂吧，又不影响我绩效。

很多时候这种“饮鸩止渴”、“竭泽而渔”的做法我基本也快认同了，然后就是改不动暂时不改以后再说吧，反正这个项目也快废掉了，毕竟大家真的很忙；

可是事实上新项目迁移的时候这些老代码还是若无其事的搬到了新项目，后续的问题依旧不断。

2、 其实不要说我们，即使是顶尖的阿里团队早些年他们的Code Review做的也并不是非常好，甚至有一些架构师质疑Code Review，他们质疑的观点大都是这些

 1）到业务团队体会一下，倒逼工期的项目有多少？订好交付日期后再要求提前1个月的有多少？现在是做到已经不容易，更不谈做得漂亮！。

　2）Code Review是一种教条，意义不大，有测试，只要不出错，就可以了。

　3）目标都是改进质量，有限的投入总希望能有最大的产出，不同沉湎改进质量的方式不一样，业务应用开发忙的跟狗一样，而且业务逻辑变化快，通用性差，Code Review的成本要比底层高。

　4）现在的主要矛盾是倒排出来的工期和不靠谱的程序员之间的矛盾，我认为Code Review不是解决这个问题的银弹。不从实际情况出发光打正义的嘴炮实在太过于自慰了 。

3、 综上，眼下Code Review要克服的大问题无疑很明显了，针对这几个问题我们给出一些建议或者措施

  1）人员能力不足 ：团队里面不知道什么是好代码 什么是坏代码；那微信公众号即是我们努力想做好的一步，希望推送好的代码给大家。

  2）结果更重要：这个我只想说如果你仅仅满足于重复的劳动而不去更多的自动化，那么你永远都很忙。

  3）需求变化的问题：需求是临时的，代码也是临时的，难道你的团队也是临时的？你肯定不这么想吧！好的代码结构才能更快的应对需求的变化。

  4）人员态度问题：懒呗，写完功能实现QA测试没问题就over了，“各自扫门前雪”，缺乏主动性，老是搬出那句话：这代码不是我写的。

  5）时间不够的问题：如果是业务逼得太紧，我觉得不应该成为不做Code Review的阻碍，需求太紧那是PM规划的问题，对于那些时节专题我们可以暂且放一马，但是总不能你所有的工作时间都在做专题？你需要从效率上面思考

总结：

当你忙得跟牲口一样，你应该停下来，问一下自己，自己成为牲口的原因，是不是就是因为自己做事时候像就牲口一样思考？————来自开源中国

怎么做Code Review？

1、首先我们已经有一套相对完善的代码规范标准，不管是自动检查还是人工检查，如果有不合理的规则可以提出我们进一步优化，对于自动检查 不同的项目有不同的特殊性，具体可以进一步沟通。

2、这边给出的建议或者大家都已经在施行的方式基本是这两种：

1）个人式

    老司机带新学员的方式，帮助新同事熟悉大度假研发的代码规范，时不时的做Code Review，切记不可累计，否则代码越来越多，以后再Code Review会非常艰难；每天坚持Code Review，大到一个功能，小到一个方法。

2）会议式

     当然我们没有代码评审的专家，所以不必要搞的很专业和正式，会议更多的是让组内其他成员来一起分享代码Code Review的心得，对已有实现的功能进行分析讲解，这样也利于组内其他成员了解别人负责的业务逻辑；不过最理想的方式是让QA团队负责这部分测试的人员也能参加，这样也方便QA人员熟悉代码逻辑，更好的熟悉需要测试的覆盖点，当然这个是比较理想化了。

另：文中有一部分内容来自开源中国的关于Code Review的一些观点，引用过来结合我们实际再做一个阐释。

本文标签： 学习

除非注明，文章均为( 冰镇宝贝321 )原创，转载请保留链接: https://bkqv5.com/archives/244.html