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