改进软件开发生命周期、提高我们向客户交付软件的速度以及软件质量都是 DevOps 的伟大前提。这些是 DevOps 运动所规定的工具和技术试图实现的目标。作为一名开发人员，我感觉可以更自由地快速进行更改，不仅可以更改源代码，还可以更改基础设施和配置代码。作为一名 DevOps 从业者，我的目标是在自由与质量和安全性之间取得平衡。如何做到这一点？我们可以使用的一个工具是代码审查。
代码审查并不是一个新概念。它们通常用作将代码更改合并到主干分支之前的手动门禁检查。这有助于通过防止开发人员在真空中工作来确保质量和安全性。它还可以帮助确保整个团队了解其项目中正在发生的事情。与技术中的任何事物一样，实现代码审查的方式有很多种，并且对于如何进行代码审查以及代码审查的目标可能存在一些困惑。让我们首先看看团队中应该由谁来执行代码审查。
应该由谁来审查代码？
很容易认为团队中更资深的开发人员应该是那些在代码进入主干分支之前审查代码的人。这只是部分正确。团队中的每个人都应该感到有权力和义务每天抽出时间来审查进入他们最常使用的存储库中的代码。为什么？这完全取决于视角，参与代码审查的人越多，我们可以利用的视角就越多。
开发人员在审查代码时的视角来源于他们多年的经验以及他们独特的经验。独特的经验有助于团队多元化，并且可以成为新的创新解决方案的来源。拥有多年的经验并不一定等同于拥有一组多样化的独特经验。这如何应用于代码审查中的初级-高级开发人员动态？在我们深入职称之争之前，让我们首先定义一下我们所说的“代码审查”是什么意思。
代码审查是一种对话
花点时间思考一下代码审查对您意味着什么。它是否是确保进入您的主干分支的代码质量的手动门禁？它是否是让更资深的开发人员，或者可能更熟悉代码库区域的开发人员审查代码的机会？这些都是很好的答案，但有一个更好的答案。
代码审查是您（提交者）和您的同事就提交到主干分支之前的更改进行对话的机会。
我们的目标应该仅仅是讨论正在进行的更改。这听起来很简单，但是，像任何数字对话一样，我们简单的人类总是试图在我们阅读的文字中暗示语气。我见过初级开发人员将代码审查中看似无害的质疑视为行动号召。他们没有参与对话，而是立即更改了代码。我想我们都可以说，我们见过更资深的开发人员在他们的代码审查和围绕代码更改的对话中使用了暗示不当语气的糟糕措辞。许多开源社区正在尝试通过行为准则声明来解决这个问题。我曾经了解过一个解决此问题的方案，我至今仍在使用，并向所有级别的开发人员推荐：评论标记。
评论标记
我之前关于初级开发人员将问题视为行动号召的例子并非凭空捏造。多年前，当我作为代码审查的一部分对拉取请求进行评论或提出问题时，我注意到了这种行为。当时这真的让我很沮丧，因为我试图进行诚实的对话，而不是试图暗示开发人员做错了什么或需要更改代码。幸运的是，我的领导层很棒，能够帮助找到问题并提出解决方案。解决方案是开始在拉取请求中使用以下标记标记我们的评论：评论、问题、阻止和推荐。它看起来像这样：
[评论] 我认为您在这里想使用 forEach 原型方法而不是 map。
[阻止] 此构造函数太大，应分解为单独的、专门的方法。
[问题] 合并功能 X 后，此类中是否需要此方法？功能 x 使其成为全局实用程序方法。
[推荐] 您可以在此处添加一个测试用例来检查负面结果。这将有助于确保未来的代码更改不会破坏我们的期望。
这可能看起来很简单，甚至可能很极端，但它确实有助于在我们的代码审查中引发对话。初级开发人员在面对更资深开发人员的质疑时，感觉更有权力和坚持自己的观点。更重要的是，他们也感觉更有权力和在代码审查中对更资深开发人员所做的更改提出质疑和评论。
将您的职称抛在脑后
通过我们关于应该由谁来执行代码审查以及代码审查是什么的讨论，应该明确一件事：初级和高级职称的意义不大。事实上，它们可能会分散代码审查的总体目标，就像我在上面描述的经历中所发生的那样。这个概念非常简单：无论您多么资深，您仍然会犯错误，无论您多么初级，您仍然可以提供有价值的创新解决方案。
我们将把关于是什么让开发人员成为初级和高级开发人员的比较留到另一篇文章中讨论。现在，让我们回到我们的代码审查对话。我们已经介绍了代码审查是什么以及为什么，但同样重要的是何时。您应该何时进行代码审查？多久进行一次？
持续进行代码审查
在过去的几年里，我见过以多种方式执行代码审查。不久前，我所在的团队每周都会举行一次一小时的代码审查会议。今天，我的团队在拉取请求过程中持续进行代码审查。如果您不熟悉拉取请求，拉取请求是在 GitHub 和 GitLab 等 Git 工具中常见的过程，开发人员正式请求将其分支中的更改合并到另一个分支中。
您和您的团队的运作方式可能有所不同，您应该始终努力找到最适合您的团队和项目的方式。我的团队和我周围的团队将代码审查用于两个目的：使代码审查过程正式化，以及根据自动化的代码质量检查阻止合并到主干。当我们就拉取请求中的代码更改进行对话时，我们的持续集成管道在后台运行，以执行项目的健全性构建、运行测试、linting 和静态代码分析。结果会反馈到拉取请求中，并有助于影响我们的代码审查。
我们多久进行这些代码审查和拉取请求？尽可能频繁。遵守精益开发实践表明我们经常进行小型提交和合并。如果是这种情况，则每天会发生多个拉取请求，并且持续进行许多对话。这可能会变得有点让人不知所措，但是，如果正在进行的更改很小，那么理论上对话也很小、简短而甜蜜。
将所有内容整合在一起
团队动态将始终在代码审查等实践的执行方式中发挥重要作用。我通常喜欢从查看有哪些拉取请求处于打开状态以及正在发生哪些讨论来开始我的一天。这为我的一天提供了一个良好而循序渐进的开始，我可以了解人们正在做什么。我通常会在整天的工作中，在我从我正在做的事情中休息一下时，回去查看是否有更多拉取请求。这对我很有效，也可能对您有效，所以我鼓励您尝试一下。
无论您决定如何进行代码审查，我通常不建议每周举行一小时的会议。首先，这可能与提交小而频繁的精益开发实践背道而驰。开发人员可能会等到代码审查后再进行任何合并或打开拉取请求。到那时，代码在他们的脑海中已经不再新鲜，并且项目中的内容可能已经发生了变化，从而影响了他们正在进行的更改。其次，如果您的团队超过两名开发人员，那么一小时的会议可能不足以充分审查所有团队成员需要提交的所有更改。这可能会导致更改在未经代码审查的情况下合并，这可能会对代码质量和安全性造成不利影响。
与其花费一个小时来深入研究代码更改，我发现最好谈论更高级别的内容。团队聚在一起讨论他们如何架构代码、他们的功能如何影响或相互关联，以及他们可能遇到的哪些障碍，这始终是一件好事。总而言之，沟通是关键，持续的代码审查应该有助于推动更多沟通。
2 条评论