关于前端:干货前端-Code-Review-的最佳实践方案

作者：@宝玉 原文：https://zhuanlan.zhihu.com/p/…

前言

我始终认为 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 通过

这样把 Code Review 作为开发流程的一个必选项后，就很好的保障了代码在合并之前有过 Code Review。而且这样合并前要求代码审查的流程，益处也很显著：

• 因为每一次合并前都要做代码审查，这样个别一次审查的代码量也不会太大，对于审查者来说压力也不会太大
• 如果在 Code Review 时发现问题，被审查者心愿代码能尽快合并，也会踊跃的对审查进去的问题进行批改，不至于对审查后果太过冲突

如果你感觉 Code Review 难以推广，无妨先尝试着把 Code Review 变成你开发流程的一个必选项。

把 Code Review 变成一种开发文化而不仅仅是一种制度

把 Code Review 作为开发流程的必选项后，不代表 Code Review 这件事就能够执行的很好，因为 Code Review 的执行，很大部分水平上依赖于审查者的认真审查，以及被审查者的踊跃配合，两者缺一不可！如果仅仅只是当作一个流程制度，那么就可能会流于形式。最终后果就是看起来有 Code Review，但没有人认真审查，轻易看下就通过了，或者发现问题也不违心批改。真要把 Code Review 这件事做好，必须让 Code Review 变成团队的一种文化，开发人员从心底承受这件事，并认真执行这件事。要造成这样的文化，不那么容易，也没有设想的那么难，比方这些方面能够参考：

• 首先，得让开发人员意识到 Code Review 这件事为本人、为团队带来的益处
• 而后，得要有几个人做好表率作用，楷模的力量很重要
• 还有，对于管理者来说，你激励什么，往往就会失去什么
• 最初，像写自动化测试一样，把 Code Review 要作为开发工作的一部分，给审查者和被审查者都留出专门的工夫去做这件事，不能光想着马儿跑得快又舍不得给马儿吃草

如何造成这样的文化，有心的话，还有很多办法能够尝试。只有真正让大家都认同和践行，才可能去做好 Code Review 这件事。

一些 Code Review 的教训技巧

在做好 Code Review 这件事上，还有一些教训技巧能够参考。

选什么工具辅助做 CODE REVIEW？

当初很多源代码管理工具都自带 Code Review 工具，典型的像 Github、Gitlab、微软的 Azure DevOps，尤其是像 Gitlab，还能够本人在本地搭建环境，依据本人的须要灵便配置。

配合什么样的开发流程比拟好？

像 Github Flow 这样基于分支开发的流程是特地适宜搭配 Code Review 的。其实不论什么样的开发流程，关键点在于代码合并到 master（骨干）之前，要先做 Code Review。

真遇到紧急情况，来不及代码审查怎么办？

尽管原则上，必须要 Code Review 能力合并，但有时候的确会存在一些紧急情况，比如说线上故障补丁，而又没有其他人在线，那么这种状况下，最好是在工作管理系统中，创立一个 Ticket，用来后续跟踪，确保后续补上 Code Review，并对 Code Review 后果有后续的代码更新。

先设计再编码

有些新人发现自己的代码提交 PR（Pull Request）后，会收到一堆的 Code Review 意见，必须要做大量的改变。这多半是因为在开始做之前，没有做好设计，做进去后才发现问题很多。倡议在做一个新性能之前，写一个简略的设计文档，表白分明本人的设计思路，找资深的先帮你做一下设计的审查，发现设计上的问题。设计上没问题了，再着手开发，那么到 Review 的时候，绝对问题就会少很多。

代码在提交 CODE REVIEW 之前，作者要本人先 REVIEW 和测试一遍

我在做代码审查的时候，有时候会发现一些非常明显的问题，有些甚至本人都没有测试过，就等着他人 Code Review 和测试帮忙发现问题。这种依赖心理无论是对本人还是对团队都是很不负责任的。一个好的开发人员，代码在提交 Code Review 之前，必定是要本人先 Review 一遍，把该写的自动化测试代码写上，本人把根本的测试用例跑一遍的。我对于团队提交的 PR，有个要求就是要在 PR 的形容中减少截图或者录屏，就是为了通过截图或者录屏，确保提交 PR 的人本人是先测试过的。这也是一个无效的辅助伎俩。

PR 要小

在做 Code Review 的时候，如果有大量的文件批改，那么 Review 起来是很艰难的，但如果 PR 比拟小，绝对就比拟容易 Review，也容易发现代码中可能存在的问题。所以在提交 PR 时，PR 要小，如果是比拟大的改变，那么最好分批提交，以加重审查者的压力。

对评论进行分级

在做 Code Review 时，须要针对审查出有问题的代码行增加评论，如果只是评论，有时候对于被审查者比拟难甄别评论所代表的含意，是不是必须要批改。倡议能够对 Review 的评论进行分级，不同级别的后果能够打上不同的 Tag，比如说：

• [optional]：在评论后面加上一个 [optional] 标记，示意这个代码行的问题可改可不改
• [question]：在评论后面加上一个 [question] 标记，示意对这个代码行不了解，有问题须要问，被审查者须要针对问题进行回复廓清

相似这样的分级能够帮忙被审查者直观理解 Review 后果，进步 Review 效率。评论要敌对，防止负面词汇；有说不清楚的问题当面沟通 尽管评论是次要的 Code Review 沟通形式，但也不要过于依赖，有时候面对面的沟通效率更高，也容易打消误会。另外文明用语，不要用一些负面的词汇。

总结

Code Review 是一种十分好的开发实际，如果你还没开始，无妨逐渐实际起来；如果曾经做了成果不好，无妨对照一下，看有没有把 Code Review 作为开发流程的必选项而不是可选项？有没有把 Code Review 变成一种开发文化而不仅仅是一种制度？

逆锋起笔 是一个专一于程序员圈子的技术平台，你能够播种 最新技术动静 、 最新内测资格 、BAT 等大厂大佬的教训、 增长本身 、 学习材料 、 职业路线 等等，微信搜寻 逆锋起笔 关注！