我正在与一位同事谈论我们使用的某些软件包的一种相当意外/不受欢迎的行为。尽管我们有一个简单的修复（或至少是解决方法），没有任何明显的副作用，但他强烈建议通过硬修补并将补丁发布到上游来扩展相关代码，希望在将来的某个时候被接受。事实上，我们会针对多个软件包的特定版本维护补丁，这些补丁会自动应用于每个新版本。主要论点是这是正确的做法，而不是“丑陋”的解决方法或脆弱的猴子补丁。另一方面，我更喜欢实用性而不是纯粹性，我的一般经验法则是“无补丁”>“猴子补丁”>“硬补丁”，至少对于（关键）错误修复之外的任何东西。
所以我想知道是否有一个共识，什么时候最好是（硬）补丁、猴子补丁，或者只是尝试解决不能完全按照人们想要的方式解决的第三方包。它是否主要与补丁的原因（例如修复错误、修改行为、添加缺少的功能）、给定的包（大小、复杂性、成熟度、开发人员响应能力）、其他原因或没有一般规则和一个应该根据具体情况决定吗？
【问题讨论】：
标签： oop language-agnostic monkeypatching patch
在我看来：
如果 'unexpected/undesired behavior' != 错误，则会指示猴子修补（或打鸭子）。
如果您认为这是 lib 中的错误，那么硬补丁和向上游推送补丁是有道理的。
如果我理解你对“解决”的定义是增加应用程序的复杂性以补偿 lib 行为，我不得不说猴子补丁绝对是一个更好的主意。
我的 .2 比索。
【讨论】：
嗯，这是相当经典的风险与收益。
补丁没有风险吗？和重的好处？猴子补丁它。如果有一点风险，只有一点好处，我不会对其进行修补，只需将修复程序插入到您的典型发布过程中即可。
【讨论】：
打补丁是“正确的事情”，原因是：对于开源软件，如果您发现了真正的错误，或者需要您怀疑其他人可能也需要的功能，那么在上游打补丁并提交补丁是一种回馈社区的方式，并有助于使软件整体变得更好。如果补丁被接受，它是对您或您公司声誉的免费 +1。没有人会因为简历上有太多有用的开源代码示例而感到难过，他们为社区做出了贡献……
并不是说我们当时总是在战壕里做正确的事。但是，如果我们要对最佳实践进行抽象讨论，那么正确的优先顺序似乎是“补丁并提交”> 聪明的解决方法 > 找到一个更好的包 > 丑陋的猴子补丁 ;-)
【讨论】：
我们缺少的一条信息是，您描述的意外行为是纯粹的错误，还是软件包的某些消费者想要的行为。
正如其他人在这里所说，这是风险和努力的权衡。在不了解您的具体情况的情况下，我无法做出任何明确的断言。
但是我的直觉是，从长远来看，修补和推动上游将导致更少的风险和努力，假设您认为您的补丁会被接受。不管你是硬补丁还是猴子补丁，你都会从中付出代价——每次更新你使用的包的版本时，你都必须测试你的补丁是否仍然有效，并可能根据情况更新它关于包的变化。使用硬补丁，您还必须重新应用补丁，但这很可能比您需要使用任一选项进行的测试/更新工作更少。
在我看来，在这种情况下打补丁有两个好处。
如果您在升级时忘记了补丁，使用硬补丁，您的补丁将完全消失，很可能会导致灾难性的可见故障。而对于猴子补丁，您的补丁仍然存在，但您不会测试它仍然具有相同的效果，在我看来，这比硬补丁完全丢失更危险。
硬补丁的另一个好处是，有了硬补丁，它最终应该被集成到包中，成本就消失了。而猴子补丁会无限期地存在，直到问题以某种方式独立解决。
如果意外行为是其他包消费者想要的，而不仅仅是一个错误，这会使我描绘的画面复杂化。在这种情况下，猴子补丁解决方案只需删除该行为。然而，硬补丁必须为那些想要它的人维护行为。
此分析忽略了您可能对包维护者和其他消费者承担的任何道德义务。
另外，我在哲学上反对猴子修补的整个概念，但这与本次讨论无关 :-)
【讨论】：