打（猴子）补丁还是不打（猴子）补丁，这就是问题
我正在和一位同事谈论我们使用的某些软件包的一个相当意外/不受欢迎的行为。尽管我们有一个简单的修复（或至少是解决方法），没有任何明显的副作用，但他强烈建议通过硬修补并将补丁发布到上游来扩展相关代码，希望在将来的某个时候被接受。事实上，我们针对多个软件包的特定版本维护补丁，这些补丁会自动应用于每个新版本。主要论点是，这是正确的做法，而不是“丑陋”的解决方法或脆弱的猴子补丁。另一方面，我更喜欢实用性而不是纯粹性，我的一般经验法则是“无补丁”>“无补丁”。 “猴子补丁”> “硬补丁”，至少对于除（关键）错误修复之外的任何内容。
因此，我想知道何时最好进行（硬）修补、猴子修补或只是尝试解决无法完全满足人们需求的第三方软件包，是否存在共识。它主要与补丁的原因（例如修复错误、修改行为、添加缺少的功能）、给定的包（大小、复杂性、成熟度、开发人员响应能力）、其他原因有关，或者没有通用规则和一个应该根据具体情况决定？
I was talking to a colleague about one rather unexpected/undesired behavior of some package we use. Although there is an easy fix (or at least workaround) on our end without any apparent side effect, he strongly suggested extending the relevant code by hard patching it and posting the patch upstream, hopefully to be accepted at some point in the future. In fact we maintain patches against specific versions of several packages that are applied automatically on each new build. The main argument is that this is the right thing to do, as opposed to an "ugly" workaround or a fragile monkey patch. On the other hand, I favor practicality over purity and my general rule of thumb is that "no patch" > "monkey patch" > "hard patch", at least for anything other than a (critical) bug fix.
So I'm wondering if there is a consensus on when it's better to (hard) patch, monkey patch or just try to work around a third party package that doesn't do exactly what one would like. Does it have mainly to do with the reason for the patch (e.g. fixing a bug, modifying behavior, adding missing feature), the given package (size, complexity, maturity, developer responsiveness), something else or there are no general rules and one should decide on a case-by-case basis ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
打补丁是“正确的事情”，这是有原因的：对于开源软件，如果您发现了真正的错误，或者需要您怀疑其他人也可能需要的功能，则打补丁并向上游提交补丁是一种方法回馈社区，并为使软件整体变得更好做出贡献。如果补丁被接受，这对您或您公司的声誉来说是免费的+1。没有人会因为他们在简历上为社区贡献了太多有用的开源代码而感到悲伤……
并不是说我们总是在当时的战壕里做正确的事情。但是，如果我们要对最佳实践进行抽象讨论，那么正确的优先顺序似乎是“修补并提交”>“修补并提交”。巧妙的解决方法>找到一个效果更好的包>丑陋的猴子补丁;-)
Patching is the "right thing" to do for a reason: With open source software, if you've discovered a genuine bug, or need a feature that you suspect others may need as well, patching and submitting the patch upstream is a way to give back to the community, and contribute to making the software better, as a whole. If the patch is accepted, it's a free +1 to you or your company's reputation. Nobody was ever sad because they had too many examples of useful, open source code they've contributed to the community on their resume ...
Not that we always do the right thing, at the time, in the trenches. But if we're going to have an abstract discussion about best practices, if seems that the right order of precedence would be "patch and submit" > clever workaround > finding a package that works better > ugly monkeypatch ;-)
我们缺少的一条信息是，您所描述的意外行为是否是一个纯粹且简单的错误，或者是否是该包的某些消费者想要的行为。
正如这里其他人所说，这是风险和努力的权衡。在不了解你的具体情况的情况下，我无法做出任何肯定的断言。
然而，我的直觉是，从长远来看，修补和向上游推送将减少风险和工作量，假设您认为您的补丁会被接受。无论您是硬补丁还是猴子补丁，您都会从中付出代价 - 每次更新您使用的软件包的版本时，您都必须测试您的补丁是否仍然有效，并且可能会根据情况进行更新关于包中的更改。使用硬补丁时，您还必须重新应用补丁，但这很可能比使用任一选项所需的测试/更新要少。
在我看来，在这种情况下修补有两个好处。
如果您在升级时忘记了补丁，则使用硬补丁时，您的补丁将完全消失，很可能会导致灾难性的可见故障。而有了猴子补丁，你的补丁仍然存在，但你不会测试它仍然具有相同的效果，在我看来，这是比完全丢失硬补丁更危险的情况。
硬补丁的另一个好处是，通过硬补丁，最终它应该集成在包中，并且成本消失。而猴子补丁会无限期地存在，直到问题以某种方式独立解决。
如果意外行为是其他包消费者想要的，而不仅仅是一个错误，那么这会使我描绘的情况变得复杂。在这种情况下，猴子补丁解决方案只需删除该行为即可。然而，硬补丁必须维持那些想要它的人的行为。
此分析忽略了您对包维护者和其他消费者可能承担的任何道德义务。
另外，我在哲学上反对猴子补丁的整个概念，但这与本次讨论无关:-)
One piece of information we're missing is whether the unexpected behaviour you describe is a bug, pure and simple, or if it's behaviour some consumers of the package want.
As has been stated by others here, it's the trade off of risk and effort. I can't make any definite assertions without knowing your specific circumstances.
However my gut feeling is that patching and push upstream will result in less risk and effort in the long run, assuming you think your patch will be accepted. Regardless of whether you hard patch or monkeypatch, you're going to have a cost from it - every time you update the version of the package you use, you're going to have to test your patch still works, and possibly update it depending on the changes in the package. With a hard patch, you're going to have also have to reapply the patch, but that'll be less work than the testing/updating you'll need to do with either option, most likely.
There are two wins for patching in this scenario, as I see it.
If you forgot about the patch when you upgrade, with a hard patch, your patch will disappear entirely, causing a catastrophic and visible failure, most likely. Whereas with a monkey patch, your patch will still be there, but you will not have tested it still has the same effect, which to my mind is a much more dangerous state of affairs than the hard-patch being missing entirely.
The other win for hard patching is that, with a hard patch, eventually it should be integrated in the package, and the cost disappears. Whereas a monkey patch will hang around indefinitely, until the issue is somehow resolved independently.
If the unexpected behaviour is something other package consumers want, and not simply a bug, this complicates the picture I paint. In this case the monkey patch solution would simply have to remove the behaviour. The hard patch, however, would have to maintain the behaviour for those who want it.
This analysis ignores any moral obligations you may have to the package maintainers and other consumers.
Also, I'm philosophically opposed to the whole concept of monkey patching, but that's not relevant to this discussion :-)
在我看来：
如果“意外/不期望的行为”！= bug，则将指示猴子修补（或鸭子打孔）。
如果您认为这是库中的错误，则进行硬修补并将补丁推向上游是有意义的。
如果我理解您对“解决办法”的定义是增加应用程序的复杂性以补偿库行为，那么我不得不说猴子补丁绝对是一个更好的主意。
我的 0.2 比索。
in my opinion:
If 'unexpected/undesired behavior' != bug, then monkeypatching (or duckpunching) would be indicated.
If you believe it to be a bug in the lib, the hard patching and pushing the patch upstream makes sense.
If I understand you definition of 'working around' to be adding complexity to your app to compensate for a lib behavior, I would have to say that monkeypatching is definitely a better idea.
my .2 pesos.
嗯，这是相当经典的风险与收益。
补丁没有风险吗？并带来大量好处？猴子补丁它。如果有一点风险，但只有一点好处，我不会对其进行猴子补丁，而只是将修复程序插入到典型的发布过程中。
Well, it's the fairly classical risk vs benefit.
Is the patch risk-free? and heavy in benefits? monkeypatch it. If there is a bit of risk, and only a bit of benefit, I'd not monkeypatch it, and just plug the fix into your typical release process.