做为开发人员，这四类Code Review方法你都知道吗？

本文翻译自：https://dzone.com/articles/4-...

转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。

---

没有人能保证他产出的代码必定是完美的，就连从事控件开发20年的葡萄城高级软件开发工程师在推出每款产品的新功能时，都要进行数百次的黑白盒测试和压力测试。好比，SpreadJS的Redo/Undo功能，在设计之初，用户必须使用多个功能和内置函数，才能处理自定义命令的撤消和重作操做，现在，用户只须要定义“执行”功能，就能够轻松实现。

下文阐述了4种主流的代码审查(code review)类型，相信做为专业的开发人员，你应该都了解它们！

每一个专业的软件开发者都知道，代码审查是任何正式开发过程当中的必要环节。但大多数开发者不知道的是，代码审查分为不少种类型。根据你项目和团队架构的不一样，每一种代码审查类型都有它特有的优缺点。

我将在本文列出几种代码的审查的类型，并详细解释它们各自是如何工做的。而且，我也将对你在什么时候作出哪一种选择给出一些建议。

好了，让咱们开始吧。

首先，在一个很高的层面，你能够将代码审查归为两大类：正式的代码审查(formal code review)，和轻量级的代码审查(light weight code review)。

正式的代码审查

正式的代码审查是基于正式的开发流程。其中最流行的实践是范根检查法(Fagan inspection)。

它为试图寻找代码的缺陷提供了一种很是结构化的流程，而且，它还能够用于发现规范(specifications)中的或者设计中的缺陷。

范根检查法由6个步骤组成：计划(Planning)，概述(Overview)，准备(Preparation)，召开检查会议(Inspection Meeting)，重作(Rework)，和追查(Follow-up)。基本的思想是：预先制定好每个步骤所须要达到的输出要求。接下来，当进行到某个过程时，你检查其如今的输出，并与以前制定的理想输出要求作比较。而后，你由此来决定，是否进入下一个步骤，或者仍需在当前步骤继续工做。

这种结构化的流程用的并很少。事实上，在个人职业生涯中，我从没遇到过哪个团队使用这种方法，并且我也不认为我能在未来看到这种状况。

我认为其缘由是，这种流程带来很大的开销，并无多少团队用到它。

然而，若是你开发的软件生死攸关，会由于有缺陷而让人丧命，那么以这种结构化的方式去查找软件缺陷就显得很合理了。

例如，你是为核电站开发软件。你可能须要一个很是正式的流程去保证最终交出去的代码是没有问题的。

但像我所说，咱们大部分开发者所作的软件都不是危及生命的，所以咱们使用一种更加轻量的代码审查方法做为正式流程的替代。

因此，让咱们来看看这种轻量级的方法。

轻量级的代码审查

现在，轻量级的代码审查在开发团队中很经常使用。

你能够将轻量级的代码审查细分为不一样的子类：

1. 瞬时的代码审查，也称为结对编程(pair programming)；
2. 同步的代码审查，也称为即时(over-the-shoulder)代码审查；
3. 异步的代码审查，也称为有工具支持的(tool-assisted)代码审查；
4. 偶尔的代码审查，也称为基于会议的(meeting-based)的代码审查。

类型1：瞬时的代码审查

第一种类型是瞬时代码审查，它发生在结对编程的情景中。当一个开发者在敲键盘写代码的同时，另外一个开发者盯着代码，注意着代码中潜在的问题，并在此过程当中给出提高代码质量的建议。

复杂的业务问题
当你须要解决一个复杂问题时，这种代码审查的方法很适用。在仔细寻找解决方案的过程当中，把两我的的脑力汇集起来，会增长成功的概率。让两个头脑思考同一个问题，并相互讨论可行的方案，这样你会更可能覆盖到问题的一些边界状况。

在遇到须要不少复杂业务逻辑的任务时，我喜欢使用结对编程。这样，有助于两我的完全理清流程中的全部不一样的可能性，保证全部状况都在代码中获得了适当的处理。

与复杂的业务逻辑不一样，有时，你也会须要去解决一个复杂的技术问题。例如，你在使用一个新的框架，或者在探索以前你没用过的一些新技术。在那种状况下，最好仍是单独行动，由于你能够根据本身的状况做出快速调整。为了弄清新技术是如何工做的，你须要上网搜索大量资料，或者阅读文档。

这时，结对编程的帮助就不大了，由于大家会成为各自获取这些知识的阻碍。

然而，当你被问题卡住以后，与你的同事交流一下解决方案，每每会帮你得到看问题的不一样视角。

相同的专业水平
考虑进行结对编程的另外一个重要方面，是一块儿工做时，两个开发者的专业水平。两个开发者最好是处于同一水平，由于这样他们才能以相同的速度一块儿工做。

让一个初级开发者和一个高级开发者进行结对编程，效果并很差。在初级开发者负责写代码的时候，坐在旁边的高级程序员可能会由于他写得太慢了而感到烦恼。如此设定，这个高级程序员的能力就被限制住了，从而浪费了时间。

而当键盘在高级程序员手上时，他又敲得太快，初级程序员跟不上高级程序员的思路。几分钟后，初级程序员就迷失在代码上下文里了。

只有当高级程序员慢下来，向初级程序员解释清楚他的作法，这种设定才合理。然而，这就不是咱们所说的结对编程了，而是一种学习的环节，其中高级程序员在教初级程序员如何解决特定问题。

可是，若是两个开发者都在同一水平，在这种设定下，他们所能取得的进展是使人惊讶的。其中有一个很大的好处是，两个开发者能相互激励，当其中一位失去注意力时，另外一位开发者能把他拉回正轨。

总结一下：结对编程适用于两个有类似经验水平的开发者处理复杂的业务问题的状况。

类型2：同步的代码审查

第二种类型是同步的代码审查。这种是，一个开发者独自编写代码，当她写完代码后，当即找代码审查者进行审查。

审查者来到开发者的桌前，看着同一块屏幕，一块儿审查、讨论和改进代码。

审查者不清楚代码的目标
当审查者不清楚这个任务的目标时，这种代码审查类型会颇有效果。它会在这种状况下发生：团队里没有优化会议(refinement sessions)，或者sprint计划会议(sprint planning sessions)，来预先讨论每一项任务。

此作法一般会致使一个结果：只有特定的开发人员才知道某项任务的需求。

这样的状况下，在代码审查以前，向审查者介绍一下任务的目标是颇有帮助的。

期待大量的代码改进
若是代码编写者缺少经验，写出的代码须要很大的改进，那么同步代码审查也会颇有效。

若是一个经验丰富的高级开发者将要对一个很初级的程序员写出的一段代码进行审查，那么，当初级程序员写完代码后就和高级开发者一块儿改进这段代码，效率是远远高于初级程序员本身一我的看的。

强行切换思路的缺点
可是同步审查有一大缺点，就是它强行切换了审查者的思路。它不只让审查者感到沮丧，也拖慢了整个团队的效率。

类型3：异步代码审查

而后咱们有了第三种类型，异步代码审查。这一类型的审查不是在同一时间、同一块屏幕上完成的，而是异步的。开发者在写完代码后，让这些代码对审查者可见，而后开始她的下一个任务。

当审查者有时间了，他会在本身的桌子上按本身的时间表进行代码审查。他而不须要当面和开发者沟通，而是用工具写一些评论。在完成审查后，那些工具会把评论和须要的改动通知给开发者。开发者就会根据评论改进代码，一样的，是以本身的时间表来作这些事情。

这个循环，会以代码改动再次被提交到审查者这里而又从新开始。开发者修改代码，直到没有评论说须要改进。最后，改动获得赞成，并提交到主分支(master branch)。

你能够看到，同步的代码审查和异步的代码审查相比有很大的不一样。

没有直接的依赖
异步代码审查的一大好处， 就是它是异步发生的。开发者不须要直接依赖于审查者，而且他们均可以按本身的时间表去作各自的工做。

屡次审查循环的缺点
这里的缺点就是，你可能会有许屡次循环的审查，它们可能会持续好几天，直到最终被接受。

当开发者完成代码后，一般须要几个小时，审查者才开始作代码审查。不少时候，审查者给出的建议只有在次日才能被开发者修复。

这样，第一次审查周期就至少用掉了一天。若是你又屡次这样的循环，审查的时间就延续至一整周了——这还不算写代码和测试的时间。

但这里有一些作法，能够避免这样的长时间间隔致使的失控。例如，在个人团队里，咱们规定，天天上午，每一个开发者在开始作其余工做以前，都要先处理积压的代码审查任务。一样的，在中午午休结束后也须要这样作。

由于在较长的休息时间后，开发者已经不处在他的代码思路中了。这时进行代码审查，你并无强制它们进行不天然的思路切换，而且可以让代码在合适的时间获得审查。

对比这种代码审查类型的优缺点，我认为，异步的代码审查应该做为每个专业开发团队的默认选项。

但在我告诉你为何我是这么想的以前，让我看看第四种代码审查类型。

类型4：偶尔的代码审查

好久之前，我曾经每月会和整个团队开一次代码审查会议。咱们坐在会议室，一个开发者展现并解释着他最近写的一段困难的代码。

其余开发者尝试寻找着潜在的缺陷，发表评论，给出如何改进代码的建议。

我不认为任何团队和长期地使用偶尔代码审查的方式。我只想到这个类型适用于的一种状况：当整个团队都没有代码审查的经验时，让把每一个人聚起来，一块儿作代码审查，这样弄几回以后，可能会帮助每一个人理解代码审查的目标和意义。

然而，从长远来看，这第四种类型并非一个合适的技术，由于让全组成员审查一段代码是很低效率的作法。

我应该选择哪一种代码审查类型呢？

好了，如今你可能会想，该选哪一种类型。

咱们讨论了正式的类型，它显然不太流行，而且较难用于实践。

而后，咱们讨论了轻量级的代码审查这一大类，而后是其中著名的4个子类型。

类型1，瞬时的代码审查，用于结对编程。当两个开发者有类似的技术组合，而且处理一些复杂的业务问题时，这种方式工做得很好。

类型2，同步的代码审查，用于审查者不清楚任务的目标时，须要开发者向其进行解释的这种状况。当开发者经验不足，写出的代码须要大量改进时，这种代码审查模式也工做得很好。

可是它的缺点是须要强行切换思路，会让审查者沮丧，以及拖慢团队开发速度。

类型3，异步的代码审查，避免了强行切换思路带来的问题，对大多数用例都工做得很好。

类型4，偶尔的代码审查，对于专业团队来讲不是一个长期的选择。能够只在团队刚刚开始代码审查时被使用。

使用异步代码审查做为默认选择

我认为，专业的团队应该把异步的代码审查做为默认的选择。由于它避免了同步代码审查的缺陷。

当审查者不能理解开发者作出一项代码修改的缘由时，可使用同步的代码审查。但在那种状况下，审查者将会去询问开发者，以得到额外的信息和说明。若是你在一个团队中工做，这样的状况应该不多发生。

若是你不在一个真正的团队中，而是和一群人一块儿工做，那么同步的代码审查就有意义了。若是审查者对你过去这几天的工做内容绝不知情，那么在开始一块儿作代码审查以前，向审查者给出一个合适的说明是很合理的。

若是你有两个开发者，他们具有类似的技能组合，而且在攻克一个复杂的业务问题，那么也有理由切换到结对编程的模式。可是，一个团队每每由许多经验水平不一样的成员组成，而且不会一直都在处理复杂的业务问题。大多数时间，你手上是复杂度在平均水平的常规任务。

所以，专业团队的最佳选择是：使用异步的代码审查做为默认选择，而后当须要时切换到同步的代码审查或者结对编程。

好了，这就是今天的内容。

你的团队使用什么代码审查的类型呢？你知道其余的、我这里漏掉的代码审查类型吗？请在评论里让我知道吧。

下次再聊。保重。

---

本文是由葡萄城技术开发团队发布，转载请注明出处：葡萄城官网

了解支持Angular、React 和 Vue 的纯前端控件集，请前往 WijmoJS

了解可嵌入您系统的在线 Excel，请前往 SpreadJS纯前端表格控件

了解最全面的.NET控件集，请前往 ComponentOne .NET开发的瑞士军刀