🔳 🍫 🤞🏽 代码审查-改进流程 👨🏼‍🎓 🧑🏿‍🤝‍🧑🏿 🧛

想象一个没有进行代码审查的团队。开发人员编写代码，无需检查就可以对主分支进行所有更改。一段时间后，功能扩展或发现错误，它们返回源代码，并且所有变量都以一个字母命名，没有遵循体系结构，质量也不是最好的。这种质量低劣的代码将累积起来，有一天，几乎没有什么创新，项目就会开始崩溃：在最好的情况下，开发时间会增加，在最坏的情况下，项目支持将变得不可能。而且尽管事实是很久以前任务已经完成并且一切都很好。

如何避免这种情况？标题中的问题的答案是代码审查。

代码检查是对错误的代码检查，可提高代码的稳定性和质量。

现在想象一下一个团队，该团队已经在进行代码审查，但是在开发人员相互宣誓的过程中，长期以来，Pull请求未被批准，任务开始冻结。从任务开始到在项目中出现的过程被拉长了，所有的工作都因此而变慢了。

拉取请求/合并请求是对项目团队（个人或一群人）的请求，用于批准和将更改应用于所选分支。创建请求请求后，将在批准之前对书面代码进行讨论。在讨论过程中可能会建议进行更改。批准后，当前更改将落入所选分支。

以下列出的建议有助于加快代码审查速度并提高其质量。

我们将问题分为三个部分，分别考虑：

技术部分：如何检查代码以及检查时要查找什么？
交流部分：在讨论中如何防止纠纷并减轻压力？
组织部分：如何使代码审查流程高效？

第1部分。检查代码

在家运行作者代码

自己运行代码，并查看更改与其余代码一起工作的方式。这有助于查找在基于Web的界面中不可见的问题区域。尝试全面查看代码，避免只关注本地更改。因此，您将快速找出代码并快速找到体系结构上的不正确之处（如有）。

记住用户体验

请注意代码中的更改将如何影响最终用户。即使是编写最精美的代码，也可能对用户毫无用处，这将导致其他任务，错误，并可能对公司和产品的声誉造成打击。

我们看一下一般逻辑

开发人员可以成功解决他们的问题，但是会破坏其他代码的工作。为了避免这种情况的发生，不仅要查看如何解决特定任务，还要查看更改将如何影响其他服务，模块和整个项目的工作。

我们看一下代码架构

代码的架构决定了将来我们将花费多少时间来扩展，添加功能或编辑错误。同样，如果项目发生更改，代码的体系结构可能会影响潜在的错误外观。理想情况下，扩展和添加新功能不应导致重构。

我们写得更容易

注意代码的复杂性：代码越简单，则越容易阅读且易于维护。摆脱复杂的代码段。

多线程

如果项目涉及到多个线程中的工作，那么请查看如果其中一个线程中的代码执行过程中存在延迟，会发生什么情况，以及如何解决这种情况。

过度优化

正如经典的Donald Knuth所写，过早的优化是万恶之源。最好只优化现在和现在需要的内容。

我们找出错误

如果无法执行一行代码，一段代码或对服务器的请求，请注意项目的行为。通常，开发人员会中断函数的执行而不会输出错误，但是需要解决这种情况。

合规

代码必须符合协议，代码样式。代码的统一性不是一时兴起，而是必要的：这样的代码更易于维护，更容易理解。

名称和外观

记住其他必须理解您的代码的程序员。可读的代码简化了其进一步的支持。名称必须易于理解并能准确描述类，对象，函数等。

代码注释

评论应回答以下问题：“为什么要这样做？”，而不是“这是如何完成的”。记住这一点。

第2部分。我们讨论

讨论的主要规则：任何评论都应针对代码，而不是针对编写者。它的作用方向相反-请勿将评论视为对您本人的批评。代码检查的任务是使您的代码更好，因为您未注意到的内容可能会被其他人注意到。同事可以提出替代解决方案，这是专业发展的潜力。重要的是要记住，对守则的讨论不是一场机智的比赛，也不是展示“谁知道更多”的节目，因此讽刺，隐藏的侵略和粗鲁的行为在其中是不合适的。

通常，拉取请求是在特殊的Web托管服务（github.com，bitbucket.org，gitlab.com等）上执行的，可以在其中查看更改并在特定的代码段上留下注释。

我们遵守协议

同样，该代码必须遵守协议。但是，如果不存在这样的协议，则不应要求同事在代码中添加空格或缩进。
在有争议的时刻，您可以在代码审查过程中与整个团队保持一致，但是在随后的代码审查中要求遵循这些规则会更好，因此每个人都更容易接受它们。顺便说一下，书面形式的书面指南可以消除几乎所有争议。

我们提供替代方案

避免使用诸如“您做错了……”，“为什么，为什么要这样写”这样的陈述？他们被视为批评并导致借口。最好在不使用作者身份的情况下编写有关代码内容的注释。还要避免命令和强迫：人们不喜欢有人命令他们，并且对这些评论持负面看法。

您可以按以下步骤进行：

我们写代码有什么问题
为什么不写更好
我们提供其他选择

我们仍然处于问题的框架之内

通常，您可以看到之前和未触及的代码注释。无需评论与任务无关的内容。任何第三方的修改都会花费很多时间，并且会被负面评价，因此最好查看一个人如何完成当前任务，而不要让他重构项目。

赞美

如果您看到有趣或有趣的解决方案，请随时给予好评。此外，这是您的同事将来继续编写出色代码的巨大动力。

所有评论均相等。

通常，一个程序员在技术上比其他程序员了解更多，这由初级，中级，高级，团队领导的等级所证明。值得一提的是，不应该强调来自一组的评论。这贬低了一些开发人员的意见，这可能导致冷漠和正式参与代码审查。当每个人的意见都同样重要时，代码审查会更有效率。

清楚表达您的想法

为了进行有效的沟通，请尽可能详细地撰写并解释每一个细节。每个人都有不同的知识水平，到目前为止，还没有人学会阅读思想。

问问题

随时问您的同事，为什么他们建议的选择比您当前的选择更好。这是学习新知识和专业发展的绝佳机会。

我们解决冲突

碰巧一个人不接受所有论据，不能提供自己的论据，拒绝做某事。此案例的一些实用技巧：

多数冲突情况可以通过以亲切态度亲自面对面解决。
您可以承认，因为您在战争中无法编写代码。
您可以吸引整个团队并共同决定如何最好地编写代码。
在当前的代码审查中，将所有内容保持不变，并使有争议的问题分离为重构任务，即任务，因为“然后修复”一词通常不会变成现实。

第3部分。改进过程

我们描述他们做了什么

我们在拉取请求标头中描述了任务的本质（或做出了单独的注释），并介绍了已完成哪些步骤。

将拉取请求分为几部分

大块的内容将被长时间监视，讨论很长时间并得到纠正。将代码分成逻辑上的小部分-这样，过程将更快。

回复所有评论

建议对每个评论进行答复，以使团队不要有任何歧义。其他开发人员应了解您阅读了他们的评论，做了必要的工作并进行了更正。不断地打开拉取请求并查看已修复的内容和不固定的内容是非常不方便且耗时的。

全部搜寻？

有不同的方法-寻找最大可能或首先对重要的建筑瞬间发表评论，然后进行更正后，注意小事情。
两种方法都有生命权。我认为第二个选项更耗时：想象一下，在更正之后，您需要再次完全检查代码，注释并再次等待更正。仔细遍历代码，发表评论然后检查更正的速度要快得多。
如果存在体系结构上的不正确之处，并且很显然在纠正了体系结构后，小错误本身就会消失，那么您不应浪费时间在代码的这一部分中评论细节。

在等大家吗

您不能等到所有人都批准请求请求并同意80％的审阅者的批准足以完成任务后再等。这将加快代码进入主分支的速度，这无疑对业务流程更有利，但可能导致团队之间的分歧以及对代码审查的漠不关心。

第二种选择是等待所有相关开发人员的批准。代码的质量将提高，但是过程本身将大大减慢速度。在选择速度还是质量方面，每个团队都应该做出自己的选择。

小东西

如果代码上没有严重的注释，那么您无需等待所有细微的错误被消除。可以在注释中指出这些内容，并立即批准请求请求-代码的编写者会感到更加镇定，他对团队的忠诚度会提高，他会感到自己受到信任。并且，当然，拉取请求的速度将增加。

结论

代码审查是开发过程的重要组成部分，它会影响整个项目，因此忽略它是很危险的。这些建议中的一些将有助于加快代码审查的速度，而其中的一些建议则会使其变得更好。希望我的经验和知识对本文的读者有用。

代码审查-改进流程