我如何处理代码审查中关于不太可能出现的边缘情况的分歧？

我在路径覆盖小组的一家机器人初创公司工作，提交拉取请求后，我的代码得到了审查。

我的团队成员已经在团队中工作了一年多，对我的代码进行了一些注释，这些注释表明我所做的工作比我认为必要的要多得多。不，我不是一个懒惰的开发人员。我喜欢优雅的代码，它具有良好的注释，变量名，缩进并能正确处理大小写。但是，我不同意他的组织类型。

我将提供一个示例：

我花了一天的时间编写测试用例，以对我所做的过渡发现算法进行更改。他曾建议我处理一个不太可能发生的模糊案件-实际上，我不确定该案件是否有可能发生。我编写的代码已经可以在我们所有的原始测试用例和发现的一些新用例中使用。我编写的代码已经通过了每晚运行的300多次仿真。但是，处理这种晦涩的案例将花费我13个小时，最好花时间去尝试改善机器人的性能。需要明确的是，迄今为止我们一直使用的以前的算法也无法处理这种晦涩的情况，并且在生成的40k报告中，没有一次发生过这种情况。我们是一家初创公司，需要开发产品。

我以前从未进行过代码审查，而且不确定自己是否太过争论。我应该保持安静，做他的话吗？尽管我强烈不同意这是对时间的充分利用，但我还是决定保持低调并做出改变。

我尊重我的同事，并承认他是一个聪明的程序员。我只是在一点上不同意他，而且不知道如何在代码审查中处理不同意见。

我觉得我选择的答案满足了解释初级开发人员如何处理代码审查中的分歧的标准。

不太可能发生的晦涩案件-实际上我不确定这是否有可能发生

在代码中没有未经测试的行为可能非常重要。如果某段代码每秒运行50次，那么大约每5.5小时运行一次就会发生百万分之一的机会。（在您的情况下，几率似乎更低。）

您可以与您的经理（或工作所在单位的高级主管中的任何人）讨论优先事项。您将更好地了解，例如，在代码性能方面进行工作还是防弹代码是头等大事，以及这种极端情况的可能性不大。您的审阅者也可能对优先级有偏见。与负责人交谈后，您会更轻松地（不同意）您对审稿人的建议，并会有所帮助。

拥有多个审阅者总是一个好主意。如果您的代码仅由一位同事审阅，请要求知道该代码的其他人或一般的代码库进行查看。同样，第二种意见将帮助您更轻松地（不同意）审阅者的建议。

在几次代码审阅期间，如果有很多重复的注释，通常会指出一个较大的问题没有得到明确传达，并且相同的问题一次又一次地出现。尝试找出更大的问题，并直接与审阅者讨论。问足够为什么的问题。当我开始实践代码审查时，这对我有很大帮助。

我可以举一个极端案例的例子，这种案例永远不会发生，从而导致灾难。

当阿丽亚娜4正在从横向开发的值加速度计被缩放以适合成16位有符号整数，并且因为加速度计的最大可能输出，缩放时，可以从未超过超过32767和最小可能从未跌破- 32768“没有必要进行范围检查的开销”。通常，应该在所有转换之前对所有输入进行范围检查，但是在这种情况下，这将试图捕获一个不可能的极端情况。

几年后，Ariane 5被开发出来，用于横向加速度计缩放的代码在“经过实践证明”的情况下以最少的测试得以重复使用。不幸的是，更大的火箭可能会期望更大的横向加速度，因此加速度计得以升级，并可能产生更大的64位浮点值。

这些较大的值“包装”在转换代码中，记住没有进行范围检查，因此1996年首次启动时的结果并不理想。这花费了公司数百万美元，并在程序中造成了重大中断。

我要说明的一点是，您不应忽略从未发生过，极不可能发生的测试用例等：它们所编码的标准要求对所有外部输入值进行范围检查。如果对此进行了测试和处理，那么灾难可能已经避免了。

请注意，在Ariane 4中，这不是错误，（因为对于所有可能的值，一切都正常运行） –这是未能遵循标准的问题。当代码在不同的情况下被重用时，它将灾难性地失败，而如果值的范围被裁剪，则可能会优雅地失败，并且为此存在测试用例可能会触发对值的审查。值得注意的是，虽然爆炸后编码人员和测试人员受到调查人员的一些批评，但大部分责任归咎于管理层，质量保证和领导层。

澄清度

尽管并非所有软件都对安全性至关重要，也不是所有软件在出现故障时都没有那么出色，但我的意图是强调“不可能”的测试仍然具有价值。这是我所知道的最戏剧性的情况，但是机器人技术也会产生一些灾难性的后果。

就个人而言，我要说的是，一旦有人向测试团队强调了一个极端案例，就应该进行测试以进行检查。实施团队负责人或项目经理可能决定不尝试解决发现的任何故障，但应意识到存在任何不足。或者，如果测试过于复杂或难以实施，则无论使用什么跟踪器和/或风险记录，都可能引起问题，以明确表明这是未经测试的情况-可能需要解决更改用途之前或防止不当使用之前。

由于以前没有处理过，因此超出您的精力范围。您或您的同事可以询问您的经理，是否值得为解决这种情况而付出努力。

使用复杂的算法，很难证明您已经想到了现实世界中出现的每个测试用例。当您有意将一个测试用例弄坏了，因为它不会在现实世界中出现时，您可能会将其他您尚未想到的测试用例弄坏了。

经常发生的另一种效果是，当您处理其他测试用例时，您的算法必然变得更加通用，因此您找到了简化方法并使之对所有测试用例都更健壮的方法。这样可以节省您进行维护和故障排除的时间。

同样，有无数的情况“野蛮”发生“不可能发生”的错误。那是因为您的算法可能不会改变，但是当没人记得这个未处理的用例时，它的输入可能会在几年后改变。这就是为什么经验丰富的开发人员在刚想到时会处理这类事情。如果不这样做，它稍后会再次咬住您。

这不是技术问题，而是业务战略决策。您会注意到建议的修复程序是针对非常模糊的情况，几乎不会发生。如果您正在编程玩具，或者正在编程说医疗设备或武装无人驾驶飞机，则在这里有很大的不同。罕见故障的后果将有很大的不同。

在进行代码审查时，在确定用于处理罕见情况的投资时，应该对业务优先级有基本的了解。如果您在解释业务重点时与同事不同意，则可能需要与业务方面的人进行讨论。

代码审查不仅仅涉及代码正确性。实际上，这远不及利益共享，知识共享以及建立团队风格/设计共识的过程缓慢而稳定的过程。

在您遇到的时候，什么是“正确的”通常是值得商，的，每个人对这是什么都有自己的看法。以我的经验，有限的时间和精力也会使代码审查变得非常不一致-取决于不同的开发人员以及同一开发人员在不同的时间，是否可能会遇到相同的问题。审阅者的思维方式是“将如何改进此代码？” 经常会建议自己自然不会增加自己的努力的变化。

作为一名经验丰富的编码人员（作为开发人员已超过15年），我经常受到编码人员的审查，而这些人员的经验比我少。有时他们会要求我做出我略微不同意或认为不重要的更改。但是，我仍然进行这些更改。只有当我认为最终结果会导致产品质量下降，时间成本非常高或“客观”的观点可以客观化时（例如，要求进行变更的原因是“不能使用我们使用的语言进行工作，或者基准测试表明所声称的性能提升不是一个）。

因此，我建议您谨慎选择战斗。为您认为不必要的测试用例编写两天的代码可能不值得花时间/精力进行。如果您使用的是诸如GitHub拉取请求之类的审阅工具，则可能会在此处对您认为的成本/收益进行评论，以表明您的反对意见，但仍同意继续工作。这算是一次平缓的回推，所以审阅者知道他们已经达到了极限，更重要的是要包括您的理由，这样，如果陷入僵局，这种情况就可以升级。您想避免加剧的书面分歧-您不想因工作差异而引起Internet论坛风格的争论-因此首先讨论问题并记录讨论结果的合理摘要可能会有所帮助，无论如何，友好的讨论都会为您决定）。

活动结束后，这是进行sprint审查或开发团队计划会议等的好话题。应尽可能保持中立，例如“在代码审查中，开发人员A确定了这个额外的测试用例，花了额外的两天时间来编写，团队认为额外的保险是有理由的吗？” -如果您实际进行此工作，则此方法会更好，因为它会给您带来积极的印象；您已经完成工作，只想轮询团队以规避风险和开发功能。

我建议您至少对模糊的情况断言。这样，将来的开发人员不仅会看到您积极地决定了此案，而且还具有良好的故障处理能力（应该已经准备就绪），这也会引起意外。

然后，创建一个断言该故障的测试用例。这样，可以更好地记录该行为，并将其显示在单元测试中。

显然，该答案假设您对“甚至不可能的可能性”的判断是正确的，而我们无法判断。但是，如果是这样，并且您的同事同意，那么对事件进行明确的声明应该是对你们俩都令人满意的解决方案。

由于您似乎很陌生，因此您只能做一件事-向团队负责人（或项目负责人）咨询。13小时是一个商业决定；对于一些公司/团队，很多；对于一些，什么都没有。现在还不是您的决定。

如果线索说“发现那个案子”，那就罚款；如果他说“不，请拧紧它”，那很好-他的决定，他的责任。

至于一般的代码审查，请放松一下。一次或两次将任务退还给您是完全正常的。

我认为我没有看到过实物的一件事，尽管它是@SteveBarnes回答中提出的：

失败的后果是什么？

在某些字段中，失败是网页上的错误。PC蓝屏并重新启动。

在其他领域，这是生死攸关的事-自驾车锁死了。医疗起搏器停止工作。或按照史蒂夫的回答：东西爆炸会导致数百万美元的损失。

有一个世界在这两个极端的差异。

最终值得花13个小时来弥补“故障”是否最终取决于您。它应该取决于管理层和所有者。他们应该对整体情况有所了解。

您应该能够对应该做什么进行一个很好的猜测。您的机器人会减速还是停止？性能下降？还是机器人的故障会造成金钱损失？失去生命？

该问题的答案应该将答案推向“是否值得公司花费13个小时的时间”。注意：我说公司时间。他们付账单，最终决定什么值得。您的管理部门应拥有最终决定权。

也许和负责安排工作优先级的人交谈？在启动时可以是CTO或产品所有者。他可以帮助您确定是否需要这项额外工作以及原因。您也可以在日常站立时带来烦恼（如果有的话）。

如果没有明确的计划工作职责（例如，产品负责人），请尝试与您周围的人交谈。后来，这可能成为每个人都将产品推向相反方向的问题。

无论您是初级开发人员还是高级开发人员，甚至是首席执行官，处理分歧的最佳方法都是相同的。

表现得像哥伦布。

如果您从未看过任何Columbo，那将是一场非常棒的表演。哥伦布（Columbo）是个非常谦虚的人物-大多数人都认为他有点发疯，不值得担心。但是，通过显得谦虚，只要求人们解释一下他就能找到他的男人。

我认为这也与苏格拉底式方法有关。

通常，您想问自己和他人的问题，以确保您做出正确的选择。不是从“我是对的，你错了”的立场出发，而是从诚实的发现立场出发。或至少尽你所能。

在您的情况下，您有两个想法，但它们的目标基本上是相同的：使代码更好。

您给人的印象是，跳过代码覆盖范围而转向可能开发的其他功能（可能是不可能的）是最好的方法。

您的同事给人的印象是，更加谨慎地对待极端情况更有价值。

他们看到了您看不到的东西吗？您看到他们看不到的东西了吗？作为初级开发人员，您实际上处于有利位置，因为您自然应该提出问题。在另一个答案中，有人提到极端情况的可能性。因此，您可以从以下内容开始：“帮助我理解-我在X，Y和Z的印象中-我缺少什么？为什么小部件会碎屑呢？我印象是在极端情况下它会弯曲。摇杆实际上为ANZA刷子带来了乐趣？”

当您质疑自己的假设和发现时，您将挖掘，发现偏见，并最终弄清楚正确的做法是什么。

首先假设团队中的每个人都是完全理性的，就像您一样，他们在团队和产品方面都拥有最大利益。如果他们做的事情没有意义，那么您需要弄清楚您不知道他们做什么，或者您知道他们没有做什么。

13小时没什么大不了的，我会做的。请记住，您为此得到报酬。只需将其归纳为“工作保障”即可。另外，最好在团队中保持良好的业力。现在，如果这需要您一个星期或更长的时间，那么您可以邀请您的经理来询问他，这是否是您最好的时间利用方式，特别是如果您不同意这一点。

但是，您听起来好像需要在团队中发挥作用。这是您获得杠杆作用的方式：寻求宽恕，无需征求许可。在您认为合适的情况下向程序添加内容（在课程范围内，即确保它完全解决了老板想要的问题..），并在事后告诉经理或您的同事。不要问他们：“如果添加功能X，可以吗？” 相反，只需在程序中添加您个人想要的功能。如果他们对新功能感到不满或不同意，可以将其删除。如果他们喜欢它，请保留它。

此外，每当他们要求您做某事时，都要“加倍努力”，并添加许多他们忘记提及的内容或比他们说的更好的内容。但是，不要问他们是否可以继续努力。只要做到这一点，并在完成后随便告诉他们。您正在做的是训练他们。

将会发生的事情是，您的经理会把您钉为“志趣相投的人”，并将开始信任您，而您的同事将开始将您视为您开始拥有该程序的领导者。然后，当您提到的事情在将来发生时，您会有更多发言权，因为您本质上是团队的明星，如果您不同意，队友会退缩。

代码审查有几个目的。您显然知道的一个问题是，“ 此代码是否适合目的？ ”换句话说，它在功能上是否正确；是否经过充分测试；对非显而易见的部分进行了适当的评论；是否符合项目的约定？

代码审查的另一部分是共享有关系统的知识。这对于作者和审阅者都是一次学习更改后的代码及其与系统其余部分的交互方式的机会。

第三个方面是，它可以对进行任何更改之前存在的问题进行回顾。通常，在检查其他人的更改时，我会发现上次迭代中遗漏的内容（通常是我自己的内容）。这样的声明“这是使它变得比以前更强大的机会”，这不是批评，也不要将其视为一体！

我现在的团队认为代码审查不仅是提交前必须毫不费力地通过代码的网关或障碍，而且主要是作为对特定功能领域进行结构化讨论的机会。这是信息共享最有效的场合之一。（这是在团队中而不是总是由同一位审阅者共享审阅的充分理由）。

如果您将代码审查视为对抗活动，那是一种自我实现的预言。相反，如果您将它们视为工作中最协作的部分，则它们将刺激您的产品以及您的合作方式不断得到改进。如果可以使评论清楚其建议的相对优先顺序，则将有帮助-例如，“在这里我想发表有用的评论”与“如果x有负面影响，就会中断”之间有很大的距离。

上面做了很多概括性的陈述，这对您的具体情况有何影响？我希望现在很明显，我的建议是对公开的问题做出回应，并商讨哪种方法最有价值。对于您建议进行额外测试的示例案例，则类似“是的，我们可以对此进行测试；我估计需要<time>才能实现。您认为这样做值得吗？还有其他事情吗？可以保证不需要测试吗？”

当我读到您的问题时，有一件让我印象深刻的事情：如果花了两天的时间来编写一个新的测试用例，那么您的新测试与您现有的测试是一个非常不同的场景（在这种情况下，它可能有很多值），或者您已经确定需要改进测试套件中的代码重用。

最后，作为对代码审查价值的一般性评论（以及对我上面所说的内容的简要总结），我喜欢Daniel Vetter在“ 维护者不扩展”中的这一说法：

至少对我来说，审阅不仅是要确保良好的代码质量，而且还在于传播知识和增进理解。最初，可能有一个人（作者（不是给定的））理解代码。经过良好的审查后，至少应有两个人对此有充分的了解，包括个别案例。

代码可以总是更好。

如果您正在进行代码审查，但看不到任何可能更好的东西或单元测试可能会捕获错误，那么并不是完美的代码，而是审查者没有完成他们的工作。是否选择提及改进是个人选择。但是几乎在您的团队任何时候进行代码审查时，都应该有人注意到可能会变得更好，或者每个人都可能浪费了时间。

也就是说，是否根据评论采取行动取决于您的团队。如果您的更改解决了问题或在没有更改的情况下增加了足够的价值，以至于您的团队接受了这些更改，则将其合并，并将其评论记录到待办事项列表中，以供以后解决。如果团队发现您的变更增加的风险或复杂性超过价值，那么您必须相应解决问题。

只需记住，任何代码至少还有一个可以测试的边缘情况，并且可以使用至少一个重构。这就是为什么最好在每个人都同时查看相同代码的情况下，以小组的形式进行代码审查的原因。这样一来，每个人都可以就所审查的代码是否可以接受（就这样）达成共识，并增加足够的价值以合并到社区基础中，或者是否必须做某些事情才能合并足够的价值。

由于您是在问这个问题，因此我假设您实际上并不是在进行“代码审查”，而是为其他人创建了拉取请求或其他提交机制，以便以不确定的方式发表评论。因此，现在您遇到了管理问题和完成的定义。我猜您的管理层是举棋不定的人，实际上并不了解代码审查的过程和目的，并且可能没有“完成的定义”（DOD）。因为如果他们这样做，国防部将明确回答这个问题，而您不必来这里问。

您如何解决？好吧，请您的经理给您一个DOD，并告诉您是否必须始终实施所有注释。如果相关人员是您的经理，那么答案是不言而喻的。

这个问题与防御性编程的优点，极端情况的危险或物理产品中的错误的灾难性风险无关。实际上，它甚至根本不是关于软件工程的。

真正要解决的问题是，当大三学生不同意或赞赏它时，小三级从业者如何处理高级从业者的指令。

成为一名初级开发人员需要注意两点。首先，这意味着虽然您可能是对的，而他是错的，但在概率平衡上，这不太可能。如果您的同事提出您看不到它的价值的建议，则需要认真考虑一下您的经验不足以使其理解的可能性。我从这篇文章中没有那种感觉。

值得赞赏的第二件事是，您的高级合伙人之所以被称为是因为他负有更多责任。如果大三学生破坏了重要的事物，那么按照指示进行操作就不会有麻烦。但是，如果高层允许他们打破它-例如，通过不在代码审查中提出问题-他们将很麻烦。

归根结底，这是您工作的隐含要求，您必须遵守商业信托公司的指示来领导他们的项目。当您有充分的理由重视他们的经历时，您通常无法屈服于老年人吗？您是否打算不听不懂的指示？您是否认为世界应该停止，直到您被说服？这些价值观与团队合作是不相容的。

最后一点。回想六个月前您编写的项目。想想你在大学写的项目。看看它们现在看起来有多糟糕-所有错误和颠倒的设计，盲点和误导的抽象？如果我告诉您，六个月后您会发现您今天所做的工作中存在同样的缺陷该怎么办？这是否有助于说明您目前的方法中有多少盲点？因为那是经验的不同。

不断地对我的代码进行注释，这些注释建议我做很多不必要的工作。

您可以提出建议，但最终决定所需的内容不是您的职责。实施管理层或（在此情况下，您的审阅者）认为必要的事情是您的工作。如果您过分或过于不同意必要的东西，您很可能会发现自己失业了。因此，接受这一点并与之相处是您专业精神的一部分。

他曾建议我处理一个不太可能发生的模糊案件

这里还有其他一些很棒的答案，这些答案表明即使仍然存在非错误（即，可能永远不会失败的错误），有时仍应进行重新处理。（例如，在构建产品的未来安全性，遵循标准等方面。）优秀开发人员的部分职责是尽可能地确信自己的代码在每次可能的情况下以及将来都会健壮以及大多数情况下，不仅在当前条件下经过测试的情况下工作，

给代码审查者的建议，以提高代码审查的业务实用性（您作为OP应该提出这样的更改）：

• 按类型记下您的评论。“关键” /“必须” /“可选” /“建议的改进” /“很高兴” /“我在沉思”。

  如果这看起来过于CDO /肛门/复杂，请至少使用2个级别：“必须修正才能通过审核，并可以合并您的更改” /“所有其他”。

处理代码审查的建议似乎不太重要：

• 在您选择的票务系统中创建一张公开票（您的团队希望使用一张票），跟踪建议

• 如果您的流程允许像Fisheye或电子邮件审阅那样对评论进行回应，则将票号＃作为对代码审阅项目的回应注释。

• 与审阅者联系，并明确询问该项目是否属于“必须修复或不会被合并/发布”类型。

  • 如果答案是“是”，但您不同意，则让项目管理负责人（PM，经理等）做出决定-完整诚实地陈述分歧。这不是关于哪个人是“正确的”，而是关于哪个项目更适合该项目，因此是PM /经理的工作。

现在，将该票证视为其他任何开发请求。

1. 如果升级后决定紧急处理，请将其视为任何紧急开发请求。取消其他工作的优先级并为此进行工作。

2. 否则，请根据为其分配的优先级及其ROI（根据您的业务范围而有所不同，如其他答案所述）对其进行处理。

您不应将此升级到管理层。

在大多数公司中，管理人员总是选择不编写额外的测试，以免花时间稍微提高代码质量，而不会浪费时间进行重构。

在很多情况下，代码质量取决于开发团队中未编写的规则，还取决于程序员的投入。

您是初级开发人员，这是您的第一次代码审查。您必须接受建议并进行工作。如果您先了解并尊重它们一段时间，就只能改善团队中的工作流程和规则，以便您了解它们为什么会存在。否则，您将成为不遵守规则并成为团队孤独者的新人。

您是团队的新手，请按照您一段时间得到的建议，找出它们为什么在那里，不要在Scrum会议中提出您遇到疑问的第一条建议。一段时间后，您会发现真正的业务优先事项毫无疑问（而且可能不是管理人员面对面告诉您的内容）。

编写满足领导/管理要求的代码非常重要。任何其他细节都只是一个“不错”。如果您是该领域的专家（请阅读：“如果您不是初级开发人员”），那么您就“有资格”解决您在整个过程中发现的小问题，而无需每次都与领导协商。

如果您认为某事不对且您是该领域的专家，那么您是对的机会很高。

以下是一些可能对您有用的语句：

• 我被要求做X，代码审查员建议我也做Y，应该这样做还是继续学习更重要的东西？
• 您是在向我建议Y，所以您可以找出至少一个能够捕获该行为的测试用例，以便我对其进行测试吗？我相信代码不会被调用。
• 也许我们不应该首先为未发现的案例建立安全的后备吗？因此，我们会尽早发现它们并随时进行修复，以便我们专注于更重要的事情。
• 好的，当我实现Y时，您能为它编写一些测试用例好吗，以便我们一劳永逸地完成该工作？
• 我被要求做X，我认为我可以做Y，除非有其他优先事项。下次为什么不提交功能请求，而不是将其作为对我的代码的评论？至少我们可以在实施该功能之前听取其他团队成员对该功能的进一步意见（通常，任何重要内容都应该是一项功能，并且应由多个人来处理；通常，代码审查应该是关于审查代码和解决方案的方法；其余是错误修复和功能）。

您是否真的认为审稿人的态度正在损害项目，或者您认为他大多数时候是对的（也许有时候他只是在评估中犯了一些小错误并夸大了这一点）？

对我来说，听起来更像是他正在编写不属于代码审查的内容，这是一种不好的做法，因为它使每个人都很难跟踪内容。但是我不知道他还发表了哪些其他评论，所以我无法在其他情况下说什么。

通常，尝试避免以下两种情况：

• 您没有按照要求进行
• 您让您的审稿人感到愚蠢

如果他实际上正在查看您的代码，那是因为管理层比您更信任他。

如果在代码审查期间关于范围存在分歧：

1. 记录代码实际涵盖的范围。没有人喜欢讨厌的惊喜。
2. 意识到范围是业务决策。在您开始使用某个功能时，范围应该已经知道了，但是如果不是，您总是可以在以后要求澄清。

如果代码审查员是制定业务决策的人，则他可以随时更改范围，即使在代码审查期间也可以，但是他并不是以代码审查员的身份进行更改。

如果无法证明边缘情况是不可能的，则必须假定它是可能的。如果有可能，那么不可避免的是它最终会发生，而不是早于以后。如果在测试中没有出现边缘情况，则可能暗示测试覆盖范围不完整。

1. 接受反馈。
2. 在对代码进行任何更改之前，请尽力为边缘情况构建测试，并查看是否会导致测试失败（证明问题存在）。如果不可能创建这样的测试用例并导致测试失败，那么您也许可以得出结论，边缘案例实际上是不可能的（尽管我会犹豫得出这样的结论）。
3. 如果测试失败，请应用适当的代码更改以通过测试。

为了产品的好，您可能希望能够制造出边缘盒并引起故障，以便您可以应用此修复程序并确信已避免了潜在的问题。

代码审查的全部目的是要更加注意代码。我们每个人都不能避免错误或疏忽。多次查看一段代码而没有注意到明显的错误是很常见的，新的眼睛可以立即看到它。

如您所说，您已经实现了一种新算法。根据新算法的行为或对其前身的观察得出有关新算法行为的结论是不明智的。

有些代码审阅者知道他们在做什么，如果他们说需要更改某些东西，那么就需要更改，而当他们说需要测试某些东西时，就需要对其进行测试。

有些代码审阅者需要通过为他人创建无用的工作来证明自己的存在。

哪一个是您要决定的，以及如何处理第二种，这更多是workshop.stackexchange的问题。

如果您使用Scrum，那么问题是您的工作是否按照预期进行（显然是这样做的），并且您可以将积压的罕见情况（可能是不可能的情况）放在待办事项列表上，优先级在哪里，以及是否可以进入冲刺阶段，然后您的审阅者可以随时选择并进行13小时的工作。如果您执行作业X，并且因为您执行作业X而意识到作业Y也需要执行，那么作业Y不会成为作业X的一部分，它是它自己的独立作业。