要(猴子)打补丁还是不(猴子)打补丁，这是一个问题 [英] To (monkey)patch or not to (monkey)patch, that is the question

问题描述

我正在和一位同事谈论我们所使用的某些软件包的一种相当意外/不希望有的行为.尽管我们这里有一个简单的修复程序(或至少是解决方法)，没有任何明显的副作用，但他强烈建议通过硬修补该修补程序并将修补程序发布到上游来扩展相关代码，希望在将来的某个时候被接受.实际上，我们针对针对每个新版本自动应用的几个软件包的特定版本维护补丁.主要观点是，这是正确的做法，而不是丑陋"的解决方法或脆弱的猴子补丁.另一方面，我更倾向于实用性而非纯粹性，我的一般经验法则是无补丁">猴子补丁">硬补丁"，至少对于(关键)错误修复以外的其他问题都是如此.

因此，我想知道是否应该(硬)修补，猴子修补或仅尝试解决与第三方软件包不完全相同的问题时是否达成共识.它主要与补丁程序的原因有关(例如，修复错误，修改行为，添加缺少的功能)，给定的程序包(大小，复杂性，成熟度，开发人员的响应能力)，其他原因还是没有一般性规则，而其中一个应该根据具体情况决定?

解决方案

我们缺少的一条信息是，您描述的意外行为是纯净，简单的错误，还是某些包装使用者想要的行为? .

正如其他人在这里所述，这是风险和努力之间的权衡.在不了解您的具体情况的情况下，我无法做出任何明确的断言.

但是，我的直觉是，假设您认为自己的补丁会被接受，那么从长远来看，修补并向上游推送会减少风险和精力.不管您是硬补丁还是猴子补丁，都将为此付出一定的代价–每次更新所用软件包的版本时，都必须测试您的补丁是否仍然有效，并可能会更新它，具体取决于在包装上的变化.有了硬补丁，您将不得不重新应用补丁，但这要比使用任何一个选项进行测试/更新(最有可能)要少.

在我看来，在这种情况下打补丁有两个胜利.

如果您在升级时忘记了补丁，则使用硬补丁，补丁将完全消失，极有可能导致灾难性的可见故障.有了猴子补丁，您的补丁仍会存在，但您尚未测试它是否仍具有相同的效果，在我看来，这比完全丢失硬补丁更危险. >

硬补丁的另一个好处是，有了硬补丁，最终应该将其集成到包装中，而成本却消失了.猴子的补丁将无限期地徘徊，直到问题以某种方式独立解决为止.

如果意外的行为是消费者希望的其他包装方式，而不仅仅是错误，那么这会使我绘制的图片复杂化.在这种情况下，猴子补丁解决方案将仅需删除行为.但是，硬补丁将必须维护那些想要它的人的行为.

此分析忽略了您可能对包装维护者和其他消费者承担的任何道德义务.

此外，我在哲学上反对猴子修补的整个概念，但这与本次讨论无关:-)

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 ?

解决方案

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 :-)

这篇关于要(猴子)打补丁还是不(猴子)打补丁，这是一个问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！