猴子补丁还是不？

Question

这是比特定于语言更普遍的问题，尽管我在使用 python ncurses 模块时遇到了这个问题。 我需要显示区域设置字符并将它们识别为字符，因此我只是快速修补了 curses 模块中的一些函数/方法。

这就是我所说的快速而丑陋的解决方案，即使它有效。 而且变化相对较小，所以我希望我没有搞砸任何事情。 我的计划是找到另一个解决方案，但是看到它有效并且运行良好，你知道它是怎么回事，我继续处理我必须处理的其他问题，并且我确信如果这没有错误我永远不会让它变得更好。

不过，在我看来，更普遍的问题是——显然有些语言允许我们在类内对大块代码进行猴子修补。 如果这是我只为自己使用的代码，或者更改很小，那就可以了。 如果其他开发人员使用了我的代码，他看到我使用了一些众所周知的模块，那么他可以假设它按照习惯工作，该怎么办？ 然后，这个方法突然表现得与应有的不同。

那么，非常主观的是，我们是否应该使用猴子补丁，如果是，何时以及如何使用？ 我们应该如何记录它？

---

编辑：对于@guerda：

猴子修补是在执行时动态更改某些代码片段的行为而不改变代码本身的能力。

Python 中的一个小例子：

import os
def ld(name):
    print("The directory won't be listed here, it's a feature!")

os.listdir = ld

# now what happens if we call os.listdir("/home/")?
os.listdir("/home/")

Answer 1

不！

特别是对于免费软件，您可以将更改添加到主发行版中。 但是，如果您的本地副本中存在记录薄弱的黑客行为，您将永远无法交付该产品，并且升级到下一个版本的curses（任何人的安全更新）将花费非常高的成本。

请参阅这个答案，让您一睹外国代码库的可能性。 链接的截屏< /a> 确实值得一看。 突然间，肮脏的黑客行为变成了有价值的贡献。

如果您确实因某种原因无法获得上游补丁，至少创建一个本地（git）存储库来跟踪上游并将您的更改放在单独的分支中。

最近我遇到了一个问题，我必须接受猴子修补作为最后的手段： Puppet 是一段“到处运行”的 ruby​​ 代码。 由于代理必须在（可能经过认证的）系统上运行，因此它不能需要特定的 ruby​​ 版本。 其中一些存在错误，可以通过在运行时对选择方法进行猴子修补来解决。 这些补丁是特定于版本的、包含的，并且目标被冻结。 我认为没有其他选择。

Answer 2

我想说不要。

每个猴子补丁都应该是一个例外并进行标记（例如使用 //HACK 注释），以便轻松追踪。

众所周知，将丑陋的代码保留在原处是很容易的，因为它可以工作，所以为什么要花更多的时间在它上面。 所以丑陋的代码将会存在很长一段时间。

Answer 3

我同意 David 的观点，猴子修补生产代码通常是这不是一个好主意。

然而，我相信对于支持它的语言来说，猴子补丁是一个非常有价值的单元测试工具。 它允许您隔离需要测试的代码段，即使它具有复杂的依赖项 - 例如无法进行依赖项注入的系统调用。

Answer 4

我认为这个问题不能用一个明确的是-否/好-坏答案来解决——必须考虑语言及其实现之间的差异。

在 Python 中，需要考虑一个类是否可以进行猴子修补（请参阅此 SO 问题供讨论），这与 Python 的稍微不那么 OO 的实现有关。 因此，我会谨慎行事，并倾向于在进行猴子修补之前花费一些精力寻找替代方案。

在 Ruby 中，OTOH 是以 OO 方式构建到解释器中的，无论类是用 C 还是 Ruby 实现，都可以修改。 甚至 Object（几乎所有东西的基类）也可以修改。 因此，猴子补丁在该社区中作为一种技术被更热情地采用。