想象以下情况：

您已经检测到您的（或其他人的）程序存在错误-给定特定输入时，函数产生错误的结果。您检查了一下代码，找不到任何错误：输入该命令后，它似乎就会陷入困境。

您现在可以执行以下两项操作之一：您可以进一步检查代码，直到找到实际原因为止；或者 或者您通过添加一条if语句检查输入是否是此特定输入来打绷带-如果是，则返回期望值。

对我来说，使用绷带是完全不能接受的。如果代码在此输入上的行为异常，那么您错过的其他哪些输入会对它产生奇怪的反应？这似乎根本不是一个解决办法-您只是把问题抛在了脑后。

由于我什至不考虑这样做，我对教授和书籍经常提醒我们有关如何使用“绷带”修复方法不是一个好主意感到惊讶。因此，这使我感到奇怪：这些“修复”到底有多普遍？

时间/截止期限压力是原因之一。

如果您在紧迫的最后期限之前遇到麻烦，而老板却气喘吁吁（可能是字面上的意思！），那么这样做并认为“我稍后会再解决此问题”非常诱人，这也许是您唯一的选择可以做。

当然，您实际返回并正确修复它的次数很少，而且相差甚远，因为您有一个新问题需要昨天解决。

尽管我们程序员不愿承认它，但编码精美的软件并不一定总能为公司或客户带来更多价值。在灾难情况下，这是双重事实，例如该软件对人们的信用卡进行了双重收费。有时，就像绷带一样，您只需要采取必要的措施来止血，并保证在患者稳定下来并真正解决核心问题后再回来。

诀窍是，一旦紧迫性消失，就很难说服任何人优先使用真正的修复工具来代替绷带。特别要考虑到，在第一个问题之后总是还有另一个紧迫的问题在等待。您只需要保持警惕，以解决快速解决方案之外的问题。

时间

我认为是第一大原因。尽管如果问题是基于代码库的，则我可能需要更多时间进行调查。我的“绷带”修复程序通常涉及CSS或UI调整。我已经编写了一些非常讨厌的内联CSS和JavaScript以快速处理它们。如果有时间的话，返回并修复它总是一个选择。

我们非常出色。

对于开发过程中的修复，我们确保在不了解根本原因的情况下不进行任何修复。然而：

• 根本原因的搜索将开始花费太长时间或停滞不前，而且期限很艰巨，
• 从根本上解决代码更改以解决根本原因的策略上不可行（更改将花费太长时间且临近截止日期）

在那些情况下，我们选择“绷带”修复。然后，我们打开内部缺陷以解决根本原因。是的，这些内部缺陷经常被以非常低的优先级处理。

对于维护流程中的修复程序，我们确保在不了解根本原因的情况下不做任何修复程序。然而：

• 非常例外地，根本原因的搜索将停止，
• 在例外情况下，可能会发生根本原因，从策略上讲是不可行的（更改不容易，客户昨天需要进行修复）。

在这些情况下，我们首先选择“包扎”临时修复，一旦客户满意，我们就会进行适当的修复，然后才能解决缺陷。

消除歧义。

• 给定一个特定的错误，很难客观地定义特定的修复程序是否是“绷带”，因为：一个人的“正确解决方案”可能是另一个人的“绷带”。
• 因此，我使用以下定义：以一种比我希望的专业方式少一些的优雅和深入的研究来修复缺陷。

首先，关于“绷带”修复的频率：

• 新代码：几乎没有。
• 旧代码：
  • 您会发现一些东西，尽管它们通常写得很优雅（请参阅下面的“数据驱动的缓解措施”），它们看上去并不像绷带，并且可以在所有代码审查中幸免。
  • 也要注意“隐形绷带”：根本不要调用该函数。由于缺少代码，甚至没有丝毫暗示存在错误的提示。
• 具有许多外部依赖性的旧代码：
  • 几乎充满了。
  • 几乎总是为过时的依赖版本而编写的，并且在将依赖关系更新到新版本之前，没有人真正阅读过依赖关系的“发行说明”。

二，我的建议：

如果该错误发生在开发团队自己的源代码中：

• 以专业的方式修复它。（如果您修复它，则拥有它。）
• 在时间紧迫的情况下，请尽力做到最好-这需要您：
  • 查看对最终用户的潜在影响：bug本身和建议的修复程序，以确定是否接受此修复程序。
  • 研究相关的代码片段（使用源代码管理工具中的历史记录信息），并与您的同事讨论（但不要占用他们太多的时间），直到您对问题和解决方案有了充分的了解。
• 始终使用缺陷跟踪系统跟踪错误。

如果该错误发生在另一个团队的源代码中：

• 推动该团队修复其错误。
• 始终将错误提交其他团队的缺陷跟踪系统。

如果该错误发生在另一家公司（或没有公司）的产品中：

• 在这种情况下，管道胶带修复（或数据驱动的解决方法）可能是修复该错误的唯一方法。
• 如果它是开源的，则无论如何都应通过某些（可能是公共的） 缺陷跟踪系统将该错误归档，以便有人可以对其进行调查。

我认为这很大程度上取决于代码库的年龄。在旧代码上，我认为这很常见，重写20岁的COBOL例程并不有趣。即使使用正在生产的适度的新代码，它也仍然很常见。

我会说这很普遍。

查看Joel Spolsky的博客文章：Duct Tape Programmer

我可以轻松地说，几乎我参与过的每个项目都必须使用某种绷带或胶带，才能按时完成任务。它不漂亮，也不干净，但是可以完成工作，因此企业可以继续运行，并且项目可以以某种方式进行。

学术界与实际世界之间确实存在差异，在实际世界中，软件实际上需要根据时间和业务限制来交付。

在某种程度上，它将修补程序推迟了，直到希望以后再解决。可悲的是，延后的修复程序经常不会发生，并且此代码已进入生产环境。

如果没有更多上下文，很难说-在您的示例中，为什么添加if语句不是正确的解决方案？是否是因为应该在某个地方处理该输入而存在其他代码块？

使用绷带修复的频率取决于许多因素，例如代码的复杂程度，最熟悉该代码的人员是否可用（负责Craig 20岁的COBOL例程的人员可能在几年前离开公司） ）以及涉及的时间范围。

面对最后的期限，有时您会为了获得更安全的解决方案而变得饱满，即使只是打上膏药而不是解决根本原因。只要您不使事情变得更糟，就可以了，但是重要的是要跟踪这一事实，即它仍然不正确并且仍需要正确地修复。

在某些情况下，这种修复实际上是可以的，并且可能是理想的（就调试所需的时间而言）。

设想一个场景，您有20个DLL，它们应该充当主要可执行文件的某种模块，但是还需要来自主要可执行文件的一些信息才能运行。

如果要在主可执行文件之外使用这些DLL，则将需要从主可执行文件中弄乱一些返回值。A.）它在此上下文中不存在，并且B.）您不希望它在此上下文中存在。

话虽如此，您最好在代码中放入一些编译器指令，以确保在对结果进行伪造时与在获得真实结果时所运行的代码完全不同。

if我没有在别人的函数内部放东西，而是{$ifdef}在函数周围放了东西-这样就不会有人将它与应该存在的东西混淆。