什么使DevOps中的代码审查良好？[DevOps]

运行良好的代码审阅在代码质量和安全性与快速创新自由之间取得平衡。

Pair programming

改善软件开发生命周期，向客户交付软件的速度以及该软件的质量都是DevOps的重要前提。这些是DevOps运动规定的工具和技术试图达到的目标。作为开发人员，感到很自由，可以快速进行更改，不仅可以更改源代码，还可以更改基础结构和配置代码。作为DevOps的从业者，目标是在质量与安全性之间实现平衡。如何？可以使用的一种工具是代码审查。

代码审查不是一个新概念。在将代码合并到主干分支之前，通常用作手动检查代码更改。通过防止开发人员独立于环境工作，这有助于确保质量和安全性。还可以帮助确保整个团队都知道他们项目中正在发生的事情。就像技术中的任何事物一样，实现代码审查的方式有很多，并且在如何操作代码审查以及代码审查的目标是什么方面可能会有些混乱。来开始看看团队中谁应该在代码审查中进行审查。

谁应该审查代码？

可以很容易地假设，团队中的高级开发人员应该是在将代码发布到主干分支之前对其进行审阅的人。这只是部分正确。团队中的每个人都应该感到有能力并且有义务抽出时间来检查进入他们最常使用的存储库的代码。为什么？这全都与视角有关，参与代码审查的人员越多，可以利用的视角就越多。

开发人员在审查代码时的观点源自多年的经验以及独特的经验。独特的经验有助于使团队多元化，并且可以成为新的创新解决方案的来源。拥有多年的经验并不一定等同于拥有一系列独特的经验。这如何适合应用于代码审查的初级-高级开发人员动态？在深入探讨标题战争之前，首先来定义“代码审查”的含义。

代码审查是一次对话

花一点时间考虑一下代码审查的意义。它是一个手动门，以确保将代码质量传递到你的主线分支吗？是否有机会让更多的高级开发人员，或者是更熟悉代码库领域的开发人员来审查代码？这些都是很好的答案，但是有一个更好的答案。

代码审查为你，提交者和同伴提供了一个机会，让他们可以在更改合并到主干分支之前就所做的更改进行讨论。

目标应该仅仅是谈论所做的更改。听起来很简单，但是，就像任何数字会话一样，我们简单的总是试图暗含所读单词的音调。我已经看到初级开发人员在代码审查中采取看似无害的询问作为行动的呼吁。无需进行交谈，而是立即更改代码。我想大家可以说，我们已经看到更多的高级开发人员使用了拙劣的措辞，这暗示着代码审查和围绕代码更改的对话中的语气不当。许多开源社区正试图通过行为准则声明解决这一问题。我一直对今天仍在使用的此问题的解决方案感到陌生，并向所有级别的所有开发人员推荐：注释标记。

评论标记

之前关于初级开发人员将问题作为号召性用语的示例并不是凭空提出的。几年前，当我在代码审查过程中对合并申请功能进行评论或提出问题时，我注意到了此行为。当时这真的让我很不高兴，因为我试图进行诚实的对话，而不是试图暗示开发人员做错了任何事情或需要更改代码。幸运的是，我有出色的领导能力，能够帮助发现问题并提出解决方案。该解决方案是开始使用以下标记在其中标记注释：评论，提问，拦截和推荐。看起来像：

[评论]我想您打算在这里使用forEach属性方法而不是map。

[拦截]该构造函数太大，应分解为单独的专用方法。

[提问]与特征X合并时，此类中是否需要此方法？ Feature x使它成为全局实用程序方法。

[推荐]您可以在此处添加测试用例，以检查是否有负面结果。这将有助于确保将来的代码更改不会违反我们的期望。

它看起来似乎很简单，甚至可能是极端的，但确实有助于在代码审查中引发对话。面对更多高级开发人员的质疑，初级开发人员感到更有能力拥有并坚持自己的意见。更重要的是，他们还感到有能力在代码审查中质疑和评论更多高级开发人员所做的更改。

不去在意职称

通过讨论谁应该在代码审查中进行审查以及什么是代码审查，应该清楚一件事：初级和高级职称的意义很小。实际上，就像上述那样，可能会损害代码审查的总体目标。这个概念非常简单：无论年纪，仍会犯错，无论多大，仍然可以提供有价值的创新解决方案。

将在另一篇文章中比较初级和高级开发人员的构成。现在回到代码审查对话。我们已经介绍了代码审查的内容和原因，但是何时审查同样重要。什么时候应该进行代码审查？频率？

连续进行代码审查

在过去的几年中，已经看到了以多种方式执行的代码审查。不久前，我所在的团队每周进行一次为时一小时的会议，以进行代码审查。今天，作为流程的一部分，团队不断进行代码审查。如果不熟悉它们，则pr是GitHub和GitLab等Git工具中常见的过程，开发人员在其中发出正式请求，以将其分支中的更改合并到另一个分支中。

您和您的团队的运作方式可能有所不同，因此应始终努力找到最适合个人团队和项目的方法。我的团队和我周围的人使用代码审查有两个目的：规范代码审查流程，并基于自动代码质量检查阻止合并到主干。在就pr中的代码更改进行对话的同时，持续集成管道正在后台运行，以执行项目的健全性构建，运行测试，整理和静态代码分析。结果将提供pr请求，并有助于影响代码审查。

多久进行一次代码审查和pr？尽可能经常地。遵循精益开发实践表明我们进行了少量提交并经常合并。在这种情况下，每天都会有多个pr，并且许多对话会持续发生。这可能会让人有些不知所措，但是，如果所做的更改很小，则理论上的对话也将很小，简短而愉快。

齐心协力

团队动态将始终在执行代码审查之类的实践中发挥重要作用。通常希望通过查看哪些请求已打开以及正在进行什么讨论来开始新的一天。它为我的一天提供了一个不错的，循序渐进的开始，可以追赶上人们正在忙于的事情。我通常会在一天内回去暂时休息一下，以检查是否有更多pr。这对我来说效果很好，也许对你来说效果很好，所以我鼓励尝试一下。

无论决定如何进行代码审查，我通常都不鼓励每周一次的会议。首先，它可以与精打细算的实践相违背，因为后者很少做并且经常做。开发人员可能会等待执行任何合并或打开请求请求，直到代码审查。到那时，代码还没有浮现出来，项目中的内容可能已经更改，从而影响了他们所做的更改。其次，如果团队有两个以上的开发人员，那么一个小时的会议可能不够长时间，无法充分审查所有需要加入的团队成员的所有变更。这可能导致变更合并而没有代码审查，并且可能对代码质量和安全性有害。

我发现与其花一个小时来研究代码更改，不如更好的沟通。对于团队来说，聚在一起讨论他们如何构造代码，它们的功能如何相互影响或相互联系以及可能遇到的阻碍总是很有益的。总而言之，沟通是关键，持续不断的代码审查应能促进更多的沟通。