devops 代码拉取_什么使DevOps中的代码审查良好？

devops 代码拉取

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

代码审查不是一个新概念。 在将代码合并到主干分支之前，它们通常用作手动检查代码更改。 通过防止开发人员在真空中工作，这有助于确保质量和安全性。 它还可以帮助确保整个团队都知道他们项目中正在发生的事情。 就像技术中的任何事物一样，有许多不同的方法来实现代码审查，并且在如何操作代码审查以及代码审查的目标是什么方面可能会有一些困惑。 让我们从查看代码审查中的团队成员开始做起。

谁应该审查代码？

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

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

代码审查是一次对话

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

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

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

评论标记

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

[评论]我想您打算在这里使用forEach原型方法而不是map。
[blocker]此构造函数太大，应分解为单独的专用方法。
[问题]此类与功能X的合并是否需要此方法？ Feature x使之成为全局实用程序方法。
[建议]您可以在此处添加测试用例，以检查是否有负面结果。 这将有助于确保将来的代码更改不会违反我们的期望。

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

把头衔留在门口

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

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

连续进行代码审查

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

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

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

放在一起

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

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

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

翻译自: https://opensource.com/article/19/7/code-reviews-devops

devops 代码拉取