如何做好Code Review？

PS：原创文章，如需转载，请注明出处，谢谢！     

本文地址：http://flyer0126.iteye.com/blog/2426055

 

一、背景

        最近随着交易业务快速扩展，研发组内新项目及新成员越来越多，如何做好Code Review，把控研发人员开发代码质量很是关键。

 

        对于大部分业务团队，谈到Code Review就会面露哀状：

        “上线时间倒排，研发工期这么紧，连码代码的时间都不够了，你还要我CR？”

        “上版的需求，这版就变了，代码生命周期太短，烂就烂吧，反正能用就行啦”

 

二、抛出问题

        下面分几个方面来分析下Code Review：

        * Code Review有没有用？

        * Code Review中的问题如何解决？

        * 如何做好Code Review？

 

三、分析问题

    1、Code Review有没有用？

        Code Review 的好处不言而喻。主要让你的代码可以更好的组织搭建，有更高可读性，且更容易维护，同时可以知识共享，相对而言，找Bug并不是那么的重要。

        总结一句话，Code Review可以直接影响你的工程能力。

 

    2、Code Review中的问题如何解决？

        Code Review中的主要问题：

        a. 编码质量较差

            原因可能是对业务不熟悉，对语言应用技巧不熟悉，也可能对公司、部门编码规范不熟悉等等，有些问题如果没人及时提醒纠正的话，只会造成在错误的道路上越走越远。

        b. 自己承担还是指导他人?

            Code Review是一个学习过程，将自己的一些经验指导给新人，从长远来看，是在“复制”你的生产力，一个人能力再强，也不可能包揽所有的任务，团队协作也是研发人员需要注重培养的软素质。

        c. 主要Review什么？

            编码风格，大家约定俗成的规范准则，从新人开始一步步坚持下去；

            代码可读性，代码写出来是叫别人可以读懂的，而且是易读的；

            全面性，业务实现异常情况考虑不全面的问题，需要老工程师指导，以免造成线上故障；

            不良代码或架构，错误的代码实现、功能函数抽象以及文件组织等，都需要尽量保持整个代码库的风格一致。

 

    3、如何做好Code Review？

        Code Review机制一定是要与团队规模和项目节奏挂钩的。

         a. Code Review 频次如何控制？

            研发前期需要技术方案设计评审，日常Code Review保证开发过程中代码质量，研发完成后项目Code Review是为了呼应前期评审过的技术方案，确认哪些方案变更了，是由于什么原因等等。

            如：大型项目，每天Code Review一次；小优化需求，merge request时候Code Review一次即可。

            Tips：Code Review一定要尽可能前置，防止测试后改动问题造成影响。

        b. Code Review 时间如何控制？

            一次不要检查过多代码，控制在1小时以内，一个[研究机构] 调查指出，太多信息或者60分钟以后，发现缺陷的能力就会降低。

        c. 作者在审核前需要注释源代码

            在他人评审之前，自己Review一遍实现思路，说不定会有意外收获呢。

        d. 使用Checklist

            可能团队内人员会犯同样的错误，一遍遍重复查找费时费力，应该整理核对Checklist来缩减经常出现的错误的排查时间，同样Checklist也有利于问题统计和跟踪改进结论。

        e. 改进问题要及时

            争取当天问题当天解决，同时Code Review新问题之前，先回顾一下之前遗留问题是否修复，做到Code Review行之有效。

        f. 培养积极的Code Review文化

            Review是团队提高代码质量的机会，也是互相学习的过程；建立接受他人评审的潜意识，我的工作产出是需要其他人Review的，这种自我激励会自然的要求自己产出更优秀的代码。

 

四、写在最后

        作为研发工程师，首先要对自己负责的业务和代码负责，这个与医生、教师的岗位职责是一样的。如果开发没有标准，对应该高标准的东西一味妥协，自己的标准一降再降，到最后吃亏的还是自己。

 

「技术架构精进」专注分享技术架构、团队管理及商业认知等，持续更新 欢迎大家关注~