这些讨厌的拉拉请求评论

他们到处都是。在Slack：“嘿，我可以在这个点评吗？”在电子邮件中：“您的评论会被要求！”在JIRA：“8个用户故事正在进行”（但代码完成）。在您的存储库中：5个打开拉拔请求。他们正在减慢交货。他们打断了你的开发人员。

我们可以责怪人民。我们可以更多地唠叨它们。我们甚至可以自动化唠叨！

让我们面对它：没有人想审查拉出请求。而且出于充分理由！它需要很多时间和工作。切尔西特洛伊描述了如何进行拉索审查权限：

除了下拉，运行和修改代码之外，我自己可以实现最大有效的拉出请求建议解决方案......在代码中。它指出了什么工作以及没有什么，并链接到有用的文档。它突出了原始开发人员的可靠工作，并在做出假设或判断之前询问问题。它解释了建议背后的推理，无论推理是否会影响职能或遵守公约。简而言之，它要求审阅者完全参与原始开发人员开始的解决方案。并且它准备审阅者在原始开发人员无法完成它的情况下对此代码负责。

审查拉出请求 - 切尔西特洛伊

做得好的，完成了软件更改的所有痛苦部分：了解更改的内容，将相关代码加载到工作内存中，让我的本地环境缩短，以查看变化，使测试运行。他们没有一个有趣的部分：重构到清晰度，改变代码并看到差异。他们需要几个小时的时间和我的集中，无论我个人想做什么。

最重要的是，他们是一个社交互动雷区！这个变量名称起初混淆了我，但现在我明白为什么他们打电话给它。我应该建议改变，并要求其他开发人员再次进行整个上下文切换吗？可能是混蛋举动。此测试不涵盖所有情况;我可以看到一个丢失的人。请求另一个，就像我是勇敢的？或者弄清楚如何自己写它，加入另一个小时？

每次评论都有成本，提交者的归属感成本。 一个负责任的评论者看起来远远超出代码。 当然，我从不想审查拉出请求。 它在精神上征税，需要很多时间，可能会损害关系，并让我无处可行的任务是我的名字。 是什么让您更容易进行无线优先事项的工作？ - 克里斯蒂娜湾 只有一个星球（@csageland）3月18日，2021年 如果这是我们所要求的，我们的优先事项可能出了问题。 热点：内部开发受到GitHub开源PR驱动开发过程的影响太多。 由零信任驱动的过程不适合一个信任的团队。 - Patricia AAS，MSC。 （@pati_gallardo）2021年3月20日

也许它说我们的团队有太多的并发任务。 “太多”我的意思是“不止一个”！

我们使用此拉索请求过程的目标是什么？有几个，但我认为主要是：安全，可理解的代码。它看起来很安全，它的剩余部分可以清楚地理解。测试可以给我们信心是安全，但只有一个人可以评估“可以理解”。

要更改代码，开发人员首先要了解代码，并了解更改。如果开发人员是最后一个更改此代码的人，那么他们就必须将其加载到内存中。他们以前明白了。如果他们审查了最后的变更 - 拉申请审查，这也应该是真的，这是一个理解一点的传播。

开发人员收集了这种知识，然后使用它来做出关于代码的决定。他们可能会迭代几次，然后他们提交他们认为安全和可以理解的东西。

但代码真的很安全和可理解吗？！？我们必须确保它！让我们再次添加这个整个过程，除了决定是批准而不是改变什么。我们将制作这种异步，是的，所以提交的可以启动整个不同的任务。如果决定是“否”，那么我们将制作另一个异步任务，每个人都可以再次进行上下文转换！

这取决于我们了解的一切我们了解产品开发流程。我们刚刚增加了WIP并通过增加进入过程（至少一个等待，真正不确定的数字）来减慢我们的响应时间。

像Patricia说，也许这一过程为开源项目开发的这个过程对我们的内部团队来说是最好的。也许有更好的方式可以一起工作。

拉索请求过程导致两个人理解的代码。如果我们的目标更高，怎么办？

怎么样：团队使所有代码变为单位。合奏工作（以前称为Mob编程的练习），具有一个共享工作产品和所有共享知识。这将是安全的，因为每个人都可以成为它，而且可以理解：整个团队都可以理解。

不是每一位团员每天都会出现。让我们从分布式系统中获取一页，并在我们制作代码更改时，需要一个团队成员的仲裁。在3个团队中至少有2个开发人员，至少有3个团队，其中5个等等，这样的方式，无论何时是时候再次改变该代码，就会参与最近的最新变革。

然后没有队列或等待，只有在获得最佳名称时才合作，完整的测试套件。每个重构都会增加整个团队对代码的理解。该团队对代码的共同理解以及它将在哪里，因此他们可以在一致的方向上进行逐渐改进。

这听起来效率低下吗？考虑队列中的效率为拉出请求，任务交换机。更不用说Perge冲突我们在拉出请求坐下来达到几天。

它听起来很浪费吗？所有那些程序员 - 时间致力于一项任务，我们可以做三个！好吧，问：这三个是最重要的？为什么不尽快得到它，然后在其他人上工作？当你从不询问许可或等待答案时，它更快，因为所有相关知识都在那里。 （当您需要邻近团队或专家的知识时，它也有助于带来其他人。）

它听起来很痛苦吗？许多人讨厌配对编程;这听起来更糟。奇怪的是，它更好。当会话中有三个或更多时，每秒凝视屏幕的压力较小。一个人的注意力可以在群体注意力保持时徘徊。一个人可以去洗手间或回答紧急问题的问题，而合奏仍然是一个合奏。对编程更令人疲惫。

这似乎是一个全天的会议吗？不，只有在我们更改代码时才。我们在一天中做了更多。还有电子邮件！我们每个人都有知识获取和知识与其他团队分享。我每天只有六个小时的专注脑电站。我的目标是五个小时的直接合作，而不是改变它之外的生产代码。

这似乎是不可能的偏远吗？它更难。设置每个人都可以连接到切换的共享开发环境。或者启动分支并使用git移动代码。打开您的视频，但将屏幕和相机设置在侧面，因此彼此看起来与查看代码不同。盯着对方都在排水。彼此一起工作正在振奋。

你的团队为此太大了吗？它确实在一次会议上用8-12人弄得荒谬。这是一种气味：你的申请太大（它需要那么多知识）;你能拆分吗？或者，有人认为添加人们会加快工作。这是一个经典的神话月份问题。

在共同努力消除所有协调工作并合并疼痛时，团队可以更小，更响应。

当我们划分人群中的任务时，我们可以说“我们正在努力”一些事情。是你组织想要的东西吗？如果是这样，那么它就会从焦点上举行支持。如果这是您需要满足的组织API，请尝试在JIRA中标记五个任务“正在进行”，然后一次一起工作。

为什么知识工作被视为个人活动？ ＆＃34;输出＆＃34;知识工作需要包括共享组织专业知识，个人工作并没有找到我们。

- Michael McCliment（@Cornazano）2021年3月18日

该团队最顺利地作为一个单位。 生产软件需要一支背后的团队，因为需要如此多的知识：软件的目的，其客户，其界面，所有的技术，它运行的数据以及世界上的数据以及世界上的所有变化（如漏洞） 它需要回应。 冗余需要几个人来持有所有这些。 要安全地改变软件，请结合所有知识。 我们可以有效地一起，或痛苦地独自：异步，彼此有很多协调和不可预测地踩踏。 我们知道代码审查改善了结果 - 与单独的编码相比，没有任何审查。 不要这样做。 代码在一起 - 在团队成员和彼此之间，团队成员和代码之间的常量，实时审查和越来越多的理解。 留下用于共享Codebase的个人集合的提取请求。 给我直接在我的团队上合作。