发烧期间如何进行有效的代码审查？

发布的最后期限是明天，您的同事最终完成了对于此发布至关重要的任务，项目经理站在您的肩膀上，并敦促您最终进行构建，并且您在审核过程中注意到同事的代码中存在缺陷。不是关键的东西，但是如果不是明天发布的东西，您将不会放手。更糟的是，您需要自己完成工作，并需要尽快完成。所以你会怎么做？尽管面临压力，您还是提出反对意见？

我发现的一种方法是将该提交临时合并到另一个分支上，并留待以后检查。如果问题只是表面上的问题，并且是唯一仍在等待代码审查的问题，则它可以工作。但是，有没有更有效的方法来处理此问题？例如，您是否建议让一个人只进行代码审查和测试？

答案是进行交流。

1. 告诉技术/团队负责人该问题
2. 与质量检查人员讨论潜在影响
3. 告诉项目管理人员（谁在您的身后）可能存在导致发行延迟的问题，您将尽快与他们联系（在几分钟或几小时内）
4. 评估此问题是否是该版本的放映停止

如果问题不是放映机，请继续发行。通知质量检查人员和您的用户有关问题，并承诺在随后的日期对问题进行修补。这只是成为生产的另一个风险。

如果这是放映机（这将对底线或某人的健康产生负面影响），请在链上进行沟通，建议您延迟发布，并说明原因。然后与开发人员联系，确定解决此问题需要多长时间，并告诉管理层您需要X分钟/小时/天。

管理层很可能会对比赛后期的演出停顿不满意，但又不想将其发布到生产中。

进行沟通，然后让管理人员拨打电话。

不要只是传达问题，将其记录下来

到目前为止，我对其他答案深感忧虑：您对这些面临典型截止日期的典型项目经理所说的话，可能会被忽略或遗忘。然后，如果出现问题，您仍然可能无法充分传达风险。

让项目经理知道您发现的问题，并让他知道您将其记录在案。您需要能够指出您的尽职调查。

记录在哪里以及告诉谁取决于您的工作环境，但绝对要包括您的老板。

识别风险和影响

您提到的问题不是关键问题，但并没有真正定义这意味着什么。充实这是您的下一步。

进行快速的风险和影响分析，以识别问题，导致问题的可能性（风险）以及如果实现风险（影响）会带来的后果严重性。使用定义明确的术语（您的项目经理应该知道），就像在上面的链接中找到的术语一样，还要提供描述以支持您的分析。

您的文档还应包括建议的操作步骤。 是的，您可以提出一个问题，但仍然建议继续进行发布。识别风险是正确的。

您的下一个发布时间是什么时候？

在完成风险/影响分析之后，如果您仍然对建议的建议犹豫不决，请考虑发布时间表。如果可以期望在两周内包含此修复程序，则可以发布一些不完善的代码。

如果有可能使解决您的问题变得“优先”（也就是说，被忽略而不再进行下一个闪亮的改进），那么这就是在发现问题后尽快记录该问题的另一个原因：如果有效地“开始”时钟”。

在这种情况下，只需通知所有人并让他们做出决定即可。这可能不是您发布的第一个错误。

截止日期是明天，但您会遇到这种情况：

项目经理站在您的肩膀上，并敦促您完成构建

这可能是个例外，因此不要仅仅因为遗漏了一个错误就对您的过程进行了任何大的改动。您应该做的是采取一些措施，以确保您不会在最后一刻进行构建。希望您以足够规律的频率进行构建，以使您确信它会成功。仍然不是最后一分钟运行它们的足够好理由。对事物进行良好的测试是增加信心的另一部分。

向负责此事的人介绍这种情况。

• 确定应提出哪些类型的问题。
• 确定选项。
• 谁做决定
• 什么时候应该决定所有这些？这可能与发布日期有关。

尽管这不能解决最后一分钟的问题，但确实提供了一种确保您将来能够处理它们的方法。尤其是在有释放压力的时候，您希望有一种以深思熟虑的方式处理事情的方法，而不是受情绪驱动。

如果有最后期限，而您的经理正站在您的身后，看着您，请您告诉他离开。他走了，或者你走了。向他解释，在压力下被迫复习，您可能不复习代码。

在这种情况下，您可以肯定会遇到一些严重的错误。

您可能很幸运，例如提交到Apple的App Store，在那里您有几天时间可以撤消新版本。但是，如果您的代码被交付给客户，那将是灾难的根源。下次我希望您的经理计划更好。

其他答案集中在您的经理试图改变质量流程的问题上。

但是，我认为您要问的是如何处理这样的事实，即代码审查至少需要2个人，因此会带来严重的延迟。例如，如果一项任务需要2h的实施和2h的审核，那么两个活动之间通常会停顿很长时间。实时任务可能需要2到3天才能完成。

这是吞吐量与延迟之间的经典问题。在软件生产机器（人类）中，上下文切换非常昂贵，因此抢占某人的工作以立即进行检查应该不是一种常见的做法。

以下是一些缓解问题的技巧：

• 在执行任务时，请分小部分发送代码，这样审阅者就不必保留很长的连续时间。
• 促进代码审查的高度优先文化。收到请求时不要停止当前的工作单元，但是当您想知道下一步该怎么做时，请始终从队列中选择一个评论。
• 如果有的话，请利用团队中的时区差异。
• 不要让一个人只进行代码审查。这是有益的。如果他对自己的任务很认真，他将无法处理任务。您的经理不会接受有人闲着的想法，只是为了节省一天的时间。