代码审查？结对编程和基于主干的开发呢？
代码审查？结对编程和基于主干的开发呢？
我经常发布关于代码审查的帖子。例如： 如何审查拉取请求 , 如何编写拉取请求 ， 和 如何强制增加您的代码审查过程 .
通常，我会收到这样的反馈：
“我们应该忘记拉取请求，拥抱结对编程，并采用基于主干的开发！”
在这篇文章中，我将讨论这个特定的反馈。我将首先分享一些关于拉取请求与基于主干的开发的想法。我将总结为什么前者至关重要，以及为什么我关注它。
有两种流行的开发模型：拉取请求模型和基于主干的开发。软件团队可能有类似其中之一或两者的变体。以下部分介绍了它们的一般外观。
拉取请求模型
拉取请求模型由开源普及。
使用拉取请求模型，代码审查是异步发生的。
您有一个主要的开发分支，通常称为 主线 .开发人员从该分支创建一个功能分支，并开始进行代码更改。一旦他们做出并测试了他们 主线 分支。
拉取请求模型在以下场景中效果很好：
- 当您有一个跨时区分布的团队时。 鉴于其异步性质，团队成员不需要参与社交编程实践。这使成员可以灵活地在自己的时间贡献代码和评论。
- 当您拥有成熟的产品时。 在这种情况下，时间不是限制——你很少需要快速迭代。您希望所有代码更改都准确无误，以降低损坏风险。
- 当您有初级开发人员时。 拉取请求可帮助您更仔细地检查他们的工作。您可以为他们提供有关如何改进其代码的功能性和可读性的具体指导。
基于主干的开发
敏捷运动普及了基于主干的开发。
在基于主干的开发中，代码审查是同步进行的。
所有开发人员都致力于 主线 分支，直接且频繁地提交给它。他们通常避免创建功能分支（但偶尔会这样做）。开发人员参与社交编程实践，在编写代码时有多个开发人员在场。这种做法的例子是 结对编程 和 合奏工作 （原名 暴民编程 ）。由于存在多个开发人员，代码审查是同步进行的，不需要异步过程。
基于主干的开发在以下场景中效果很好：
- 当您有一个位于同一地点的团队或在同一时区的团队时。 这简化了同步的社交编程会话的调度。
- 当你有一个新产品，并且需要快速迭代时。 在这种情况下，时间是一种约束。你正处于探索阶段——你的客户会改变他们想要的东西，你需要快速转向改变你的产品。
- 当您拥有大多数高级开发人员时。 您无需密切关注他们的工作，也无需对他们的代码给予太多指导。你想给他们完全的自主权。
拉取请求击败基于主干的开发
基于主干的开发是核心思想之一 持续交付 .持续交付的其他核心理念涉及围绕构建、测试和部署的自动化技术。这些想法被谷歌、亚马逊、Meta、Netflix、优步和许多其他公司广泛采用。
一个想法是 ** 不是** 被这些公司广泛采用？基于主干的开发！绝大多数软件开发团队——包括上述公司的大多数团队——都使用拉取请求模型。
但为什么？为什么这么多团队采用持续交付的原则，却忽略了其中的一个中心思想？
很难说。这篇有见地的文章—— 开源如何击败敏捷 ——Lorin Hochstein 提出了一个令人信服的推测：
“在开源中，根据定义，整个过程都是可见的。我们可以观察项目如何进行代码审查、集成测试、新功能规划等。在敏捷起源的世界里，我们做不到。我们可以获得顾问的书籍和演讲，但我们看不到他们如何运用他们的技能来解决他们在敏捷中遇到的特定困难……因为开源成功地让敏捷失败的工作变得可见，所以开发人员有更多的机会成为比敏捷开发人员更好的开源开发人员。”
简而言之：在影响现代软件开发方面，开源的可见性为拉取请求提供了优势，而不是敏捷和基于主干的开发的隐藏、降低的可见性。
关于什么 结对编程 ?
结对编程是一个很好的工具。做得好，它可以带来更好的指导、知识共享和团队士气。它在基于主干的开发模型中特别有效，但也可以在拉取请求模型中使用。
根据情况，团队可能决定使用结对编程、异步代码审查或两者兼而有之。使用一种工具并不强制完全消除另一种工具。
代码审查这个术语呢？
之前，我提到我发布了关于 代码审查 经常。但这经常是一个争论点，有机会在这里澄清一下。
如前所述， 代码审查 发生在 两个都 拉取请求模型 和 基于主干的开发。但是由于拉取请求模型如此占主导地位，大多数开发人员更容易认识到 代码审查 在该模型的上下文中——例如，异步审查。因此，我的帖子通常假设读者在该模型中操作。
我用这个词 代码审查 因为 拉取请求 会导致太多混乱：我给出的提示与 GitHub 上下文无关。它们不是专门为开源开发人员准备的。相反，它们适用于在团队中运作的开发人员，为公司的产品做出贡献。
各种命名法实际上让我很头疼，让我的内容更难写：
在拉取请求模型中操作是一项关键技能——我是来帮忙的
拉取请求与基于主干的开发的话题是整个行业的普遍争论。许多有影响力的开发商都参与进来，争论双方。
我在这里的目的不是告诉你偏爱其中一个。每个组织都应该选择适合他们的风格。
然而，有几件事是明确的：拉取请求模型占主导地位——出于上述原因或其他原因。它适用于许多公司。在许多情况下，它嵌入在公司文化中。它不会很快消失。
成千上万的开发人员参与拉取请求模型，并将继续这样做。这些开发人员需要帮助——因为在该模型中取得成功是一项关键技能。
2021 年，Dropbox 公开发布了他们的 工程职业框架 .该文档详细说明了各种角色（如软件工程师）的预期关键行为。许多大公司都有类似的内部准则。
包含在 Dropbox 中：
- “我确保代码审查中的代码质量很高。”
- “我……为我的团队设定并保持质量和最佳实践的标准（例如通过代码和设计审查）”
- “我征求并提供诚实和建设性的反馈，以同理心帮助他人学习和成长。”
不可否认——代码审查的成功对于想要升级的软件工程师来说至关重要。
考虑到所有这些，让我们重新回顾一下本文开头的反馈。
当我发布关于代码审查的帖子时，我经常会收到这样的反馈：
“我们应该忘记拉取请求，拥抱结对编程，并采用基于主干的开发！”
我可以看到这条反馈对于那些希望影响组织采用基于主干的开发模型的人来说是一个有用的论据。但如前所述，这不是我的立场——我的立场是为已经参与拉取请求模型的开发人员提供指导。
在这种情况下，这种反馈会适得其反。我们不能简单地告诉所有开发人员忘记拉取请求，转而使用基于主干的开发。
这个建议不适用于亚马逊的初级软件工程师，他刚刚收到了 20 条关于 PR 的评论，并且不知道如何为自己辩护。
这个建议不适用于微软的中层软件工程师，他们盯着公关，不知道如何提供建设性的反馈。
该建议不适用于 Uber 的高级软件工程师，他发现自己是团队代码审查过程中的瓶颈。
所以我会继续写代码审查，希望对你有所帮助。
喜欢这篇文章吗？
事实证明，代码审查是我的事。看看我的视频课程， 掌握代码审查 ！个人和 团队许可证 可用的。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
