翻译|崔浩审稿人|孙淑娟1.一开始，为了提高代码质量，需要将批判性思维带入编程。因此，需要将工程方法应用到代码的审查过程中。虽然软件工程师在谈论抽象类和函数时有信心，但在谈论“管理”时这种信心消失了。在整个编程过程中，由于各种原因会出现大量的缺陷，这就需要进行代码审查，找出这些缺陷，以保证软件质量。本文将从不同的角度看待代码审查并提出改进建议。在《软件工程的事实与谬误》一书中，有这样的描述：“在运行第一个测试用例之前，严格的检查可以消除软件产品中高达90%的错误。”代码审查，但可以理解，不同类型的检查确实有助于软件质量。1976年，MichaelFagan在他的文章《设计和代码检查以减少程序开发中的错误》中提出了代码检查的想法。其中包括以下三种类型的检查：设计检查单元测试前的代码检查单元测试后的代码检查MichaelFagan关于设计和规范检查的文章中的一个场景Fagan的工作没有提出新的代码审查方法，但记录了已经存在的现象，并为他们辩护。然而，这篇文章是最早的记录代码检查的书面作品。代码检查（Codeinspection）看起来像现代的代码审查（Codereview）。那么，为什么我们今天缺少其他类型的检查呢？2、今天为什么只有codereview的假设比如：GitHub、BitBucket或者GitLab都内置了代码检查工具，天然适合Gitflow、GitHubflow等方式。设计活动中使用了哪些工具？这与UI/UX无关，仅与代码结构有关。您可能听说过CASE或UML工具。在我工作过的7家公司中，我还没有看到他们被认真使用过。在HackerNoon上，关于“UML”的搜索查询只有两个结果。所以在没有解决方案设计过程的情况下，不需要引入设计检查。在我带领的团队中，Miro被用于界面设计。整个设计过程令人满意：与其他图表工具一样，您可以快速开始绘图而不是解决设计问题。我们要解决的问题和工具提供的功能是分开的。这里有一段来自?一书中的一小段话支持了这个观点。“......如果我们只是做工具能做的事——那么我们将永远受限于工具能做的事。”3.现有代码审查存在哪些缺陷？让我们从不同的角度来看以下过程，每个过程都存在重大问题。1.BPMNPerspectiveBPMN是建立一个业务流程建模符号系统。它使用动作、事件、逻辑网关、消息等手段来描述过程。如果您想开发算法，我什至建议使用它，因为它比流程图更具描述性。让我们使用这个符号来描述代码审查过程并对其进行分析。我使用基于文本的工具来生成图表。经典的代码审查流程图从创建PR（PullRequest）开始，下一步是通知审查者，可以说是简化了。“嘿嘿，我的PR在等你呢！这里有一个等待，然后reviewer进入task进行review，有可能马上就合并一个PR。当然也有相反的情况：一些会提出修改意见，此时代码的作者可能已经在进行下一个任务，所以需要等待一段时间，当作者带着修改意见返回任务时，需要恢复上下文，解释comment，修复，修复之后，下一步就是通知reviewreviewer重新进行codereview，这种情况似曾相识，没错，codereview和repair是一个无限循环，上面的描述只是这个循环一次，reviewer总能发现新的问题，抛出新的问题。或者整个循环在程序作者其他工作的影响下，永远等待下去。我们是否希望无限循环成为我们日常操作的一部分？我不确定，因为交货更快通常是什么我们想要。2.解决问题的方法有时，团队中的高级开发人员或架构师会担任评审人员。他们希望有一个一致的代码库，同时坚持一些编程方法和模式。也就是说，reviewer有自己的一套idea（visions），开发者当然也有自己的idea。通常，两波人并不知道对方的意图。这需要一种方法来连接他们的观点和意见，这有助于他们站在同一水平上思考问题，但在实践中这种情况很少发生。让我们看看下面的图片。在经典的代码审查过程中，代码创建者和审查者的观点会随着时间的推移而发生分歧，这在代码审查中可以看出参与者的两种心态是不同的。第一次迭代后，他们开始对齐，但还有一段路要走。审阅者调整自己的视野，而代码编写者则根据建议采取行动。就好像“你要了一所房子，结果出乎你的意料！这不是你所期望的”。想象一下，你已经要求某人让某事发生。完成后，你会对结果感到惊讶。不要惊慌和吃惊，因为你没有告诉执行者做这件事的“决策框架”，导致结果偏离了你的预期。3.从人际关系的角度来看codereviewmemo的图片本身就说明了问题。审查的代码量越少，发现的问题就越多，代码量越大，“不会发现问题”。坦率地说，如果你是审稿人，你会要求你的同事花很长时间（几天）来完全修复一个设计问题吗？尤其是在迭代的冲刺阶段，开发时间已经很紧迫的时候，会做吗？恐怕，你是想快速完成功能，合并代码发布吧？！另一方面，如果有一个代码修复需要更改系统中的许多地方，您会决定更改它吗？虽然，精益生产的思想并没有影响到编程。然而，MaryPoppendieck和TomPoppendieck在《精益软件开发》中描述了软件开发的7种浪费。它们包括：PartiallyDoneWorkExtraFeaturesRelearnHandoverDelaysTaskSwitchingPitfalls下面，我们花一点篇幅展开这7点：PartiallyDoneWork。审查代码没有得到足够的重视，审查只是提高代码质量的开始，而不是软件开发的结束。有一种有趣的心态：“开发完成，review任务提交，剩下的不是我的事！”，导致codereview是一个“三通”的地方，只有当上级要求引起重视。再学习。看到BPMN图上的重新学习，程序员在收到建议的更改时可能手头有其他任务。开始修改review代码的时候，已经有一段时间任务完成了。为了根据意见进行修改，业务和技术背景不得不重新审视，这就是重新学习。恢复业务和技术上下文对程序员有开发成本。（这也适用于审稿人）交接。代码的交接，修改方案的描述，团队成员之间的沟通存在于中间，有沟通就有损失。延迟。代码审查设计包含了我们之前讨论的两种类型的延迟：修改本身的延迟和想法的延迟。任务切换。人们暂停他们的任务，并给予一些关注的审查。缺点。审查有助于发现表面问题，但无助于发现造成最大损害的设计缺陷。前述缺乏向研究人员提出重大改变的动力导致了该项目的大量缺陷。我们已经以多种方式讨论了代码审查的问题。我们可以做些什么来解决这些问题？四、重新设计代码审查在这一节中，我们将解决上面提出的问题，看看如何优化它们。1.修复流程结构代码审查流程图有代码作者等待审查完成，以及审查者概述问题后的结对编程会话。在此过程中，与之前的过程相比，可以看到几个显着的变化。不再有潜在的无限审查循环。还会处理未知的等待时间。无需恢复上下文或为代码作者解释反馈。评论只是提醒。这个过程发生的核心条件是什么？团队需要一个额外的角色。这意味着有人会做一些副业，例如：处理技术债务，或修复优先级较低的错误。当codereview出现时，这个人会立即放下当前的任务去做PR工作。2.修复概念差异。我们在codereview中讨论的，在开发过程中做出的任何决定，无论何时何地都需要有同理心，一定要站在对方的角度去思考，而不是站在自己的角度去思考。设计决策需要在设计完成时做出，而不是在编码阶段。当然，这里还需要一个额外的评审类型：设计评审。有时，问题的挑战性足以花一些时间来计划，与知识渊博的同事聊天可能会有所收获。有一句著名的军事格言说：“没有战斗计划能在与敌人接触后幸存下来”。翻译成系统语言应该是：“当第一个反馈来的时??候，系统肯定需要调整。”.在编程中，反馈是将设计实施到系统中的问题。因此，一些以前做出的决定，在需要修改的时候就应该修改。修改过程中，由于理念和眼光的不同，会再次与审稿人产生分歧。AdamThornhill在他的《软件设计X射线》一书中提出了一种方法。这就是为什么我建议您尽早进行初步代码演练。通常的做法是在完成三分之一的过程中介绍和讨论每个功能，而不是等待功能完成。少关注细节，多关注整体结构、依赖关系以及设计如何与问题域保持一致。当然，完成三分之一是主观的，但应该是基本结构到位、问题理解清楚、初步测试存在的地步。在这个早期阶段，重新设计仍然是一个可行的选择，发现潜在的问题可以带来巨大的回报。受以上启发，我为我的团队创造了一个词：“建筑评论”。我希望它有助于反映竞选背后的想法。在代码审查过程中，代码创建者和审查者的观点会随着时间的推移而出现分歧。3、精益视角的推荐处理方式CodeReview推荐的处理方式可以消除或极大地解决浪费行为。部分完成的工作。不允许在代码作者的预期时间内切换到另一个任务，因此在用户意义上不存在部分完成的工作。具有较低优先级的部分完成的活动是权衡的结果。再学习。由于完成编码和结对编程之间的时间非常短，因此不会发生重新学习。延迟。我们大大减少了代码审阅者的延迟并消除了作者的延迟。任务切换。对于作者，不再允许，对于审稿人，可以由管理员解决。缺点。修复设计缺陷现在更容易，而且其中最重要的缺陷是可以修复的。五、附加思考我们已经讨论了单一作者和单一评审者的代码评审方法和过程。当更多审查员出现时，问题会成倍增加。尝试引入推荐流程时面临的两个最具挑战性的问题：首先，开发人员将审查阶段视为一项工作。当多余的人被引入日常工作时，经理们会感到震惊。解决这个问题的方法是适当的冗余和更快的审查。第二个问题更复杂。在这里我想引用丹尼尔瓦坎蒂的书中的一段话《可预测的敏捷指标》。联邦快递采用了多种策略，但最重要的可能是联邦快递在任何时候都有空机。是的，我说的是空飞机。这样，如果一个位置被淹，或者如果一个包裹被遗弃，如果预定的飞机已经满员，那么一架空飞机将被转移到问题位置（应该说是及时）。任何时候，联邦快递都有“备用飞机”！如果您是经理，请在下次计划最大化利用率时考虑以下问题。（译者：这是让管理者考虑在产量最高和成本上升最低的情况下，为了软件质量，需要部分备份和冗余）我们对这次更新满意吗？是的，它看起来比我们现在的位置更好。我们能做得更好吗？我们可以。如果可以在不影响质量的情况下实现目标，则可以取消代码审查。为了实现这个目标，我们需要构建一个辅助决策框架来帮助开发者应用最佳实践。当然，我们从未听说过这样的框架，但IDE内的linters是朝着它迈出的一步。原文链接：https://hackernoon.com/code-reviews-is-inherently-flawed-heres-how-to-fix-it译者介绍崔浩，社区编辑，资深架构师，18年软件开发和架构经验,10年分布式架构经验。
