我一直认为 Code Review(代码审查)是软件开发中的最佳实践之一, 可以有效提高整体代码质量, 及时发现代码中可能存在的问题. 包括像 Google, 微软这些公司, Code Review 都是基本要求, 代码合并之前必须要有人审查通过才行.
然而对于我观察到的大部分软件开发团队来说, 认真做 Code Review 的很少, 有的流于形式, 有的可能根本就没有 Code Review 的环节, 代码质量只依赖于事后的测试. 也有些团队想做好代码审查, 但不知道怎么做比较好.
网上关于如何做 Code Review 的文章已经有很多了, 这里我结合自己的一些经验, 也总结整理了一下 Code Review 的最佳实践, 希望能对大家做好 Code Review 有所帮助.
Code Review 有什么好处?
很多团队或个人不做 Code Review, 根源还是不觉得这是一件有意义的事情, 不觉得有什么好处. 这个问题要从几个角度来看.
首先是团队知识共享的角度
一个开发团队中, 水平有高有低, 每个人侧重的领域也有不同. 怎么让高水平的帮助新人成长? 怎么让大家都对自己侧重领域之外的知识保持了解? 怎么能有人离职后其他人能快速接手? 这些都是团队管理者关心的问题.
而代码审查, 就是一个很好的知识共享的方式. 通过代码审查, 高手可以直接指出新手代码中的问题, 新手可以马上从高手的反馈中学习到好的实践, 得到更快的成长; 通过代码审查, 前端也可以去学习后端的代码, 做功能模块 A 的可以去了解功能模块 B 的.
可能有些高手觉得给新手代码审查浪费时间, 自己也没收获. 其实不然, 新人成长了, 就可以更多的帮高手分担繁重的任务; 代码审查中花时间, 就少一些帮新人填坑擦屁股的时间; 良好的沟通能力, 发现问题的能力, 帮助其他人成长, 都是技术转管理或技术上更上一层楼必不可少的能力, 而通过代码审查可以有效的去练习这些方面的能力.
然后是代码质量的角度
现实中的项目总是人手缺进度紧, 所以被压缩的往往就是自动化测试和代码审查, 结果影响代码质量, 欠下技术债务, 最后还是要加倍偿还.
也有人寄希望于开发后的人工测试, 然而对于代码质量来说, 很多问题通过测试是测试不出来的, 只能通过代码审查. 比如说代码的可读性可维护性, 比如代码的结构, 比如一些特定条件才触发的死循环, 逻辑算法错误, 还有一些安全上的漏洞也更容易通过代码审查发现和预防.
也有人觉得自己水平高就不需要代码审查了. 对于高手来说, 让别人审查自己的代码, 可以让其他人学习到好的实践; 在让其他人审查的同时, 在给别人说明自己代码的时候, 也等于自己对自己的代码进行了一次审查. 这其实就跟我们上学时做数学题一样, 真正能拿高分的往往是那些做完后还会认真检查的.
还有团队规范的角度
每个团队都有自己的代码规范, 有自己的基于架构设计的开发规范, 然而时间一长, 就会发现代码中出现很多不遵守代码规范的情况, 有很多绕过架构设计的代码. 比如难以理解和不规范的命名, 比如三层架构里面 UI 层绕过业务逻辑层直接调用数据访问层代码.
如果这些违反规范的代码被纠正的晚了, 后面再要修改就成本很高了, 而且团队的规范也会慢慢的形同虚设.
通过代码审查, 就可以及时的去发现和纠正这些问题, 保证团队规范的执行.
关于代码审查的好处, 还有很多, 也不一一列举. 还是希望能认识到 Code Review 和写自动化测试一样, 都是属于磨刀不误砍柴工的工作, 在上面投入一点点时间, 未来会收获代码质量, 会节约整体的开发时间.
该怎么做?
现在很多人都已经有意识到 Code Review 的重要性了, 只是苦于不知道如何去实践, 不知道怎么样算是好的 Code Review 实践.
把 Code Review 作为开发流程的必选项而不是可选项
在很早以前, 我就尝试过将代码审查作为代码流程的一部分, 但只是一个可选项, 没有 Code Review 也可以把代码合并到 master. 这样的结果就是想起来才会去做 Code Review, 去检查的时候已经有了太多的代码变更, 审查起来非常困难, 另外就算审查出问题, 也很难得以修改.
我们现在对代码的审查则是作为开发流程的一个必选项, 每次开发新功能或者修复 Bug, 开一个新的分支, 分支要合并到 master 有两个必要条件:
所有的自动化测试通过
有至少一个人 Code Review 通过, 如果是新手的 PR, 还必须有资深程序员 Code Review 通过
来源: https://www.cnblogs.com/dotey/p/11216430.html