Rails中的Monkeypatching

Question

monkeypatching是一种好的开发实践吗？我应该什么时候做monkeypatch，而不是，比方说，派生一个gem，然后在派生的项目上打补丁？

Answer 1

一般来说，猴子补丁从来都不是一种好的做法。但是，我经常将它用于与应用程序截然不同的非常特殊的情况。在所有其他情况下，我更喜欢派生gem或插件，并将派生的gem直接安装到我的应用程序的gem文件夹中。

我也有一些工具模块，用猴子来修补一些类，将特殊目的的行为注入到一些标准类中，以便在不同的应用程序中重用-但这些模块仍然足够特殊，对公众没有用处，或者创建fork是不可行的。

因此，归根结底，这是一个专业化和兼容性的决定。永远记住，猴子补丁更有可能破坏你在项目中可能使用的其他插件或gem的预期行为。在更新工作应用程序生态系统(或外部支持生态系统，如Rails及其依赖项)中的组件后，这可能会变得更加紧迫。

Answer 2

如果您练习负责任的鸭子出击，它可以像gem的特定于项目的本地副本一样容易支持。这完全取决于您记录任一解决方案的升级问题的努力程度。很容易说，您或支持开发人员不会在一年后不计后果地替换供应商/ gem中的gem，但它确实发生了。分叉项目，在本地修补它，然后提交一个拉取请求并让它回到主gem中，这是理想的情况。

不过，如果你选择了这条路线，你需要遵守几条关于鸭子出击的规则：

• 补丁必须放在一个明显的位置。lib/gem_name_extsions.rb是我作为支持开发人员检查缺陷的第一个地方。
• 这个补丁应该有大量的文档围绕着它。它应该概述潜在升级nightmares.
• The补丁应该在不同的模块上完成，然后包含在原始模块/类ActiveSupport样式中。这允许支持开发人员调用problem_method.ancestors并查看正在进行的monkeypatch。

这将是一种保留旧方法的方法(为了好玩和游戏)，并允许您使用problem_method.ancestors()更容易地跟踪它。

#lib/mongomapper_extensions.rb
module MongomapperExensions
  module ProblemClassExensions
    alias :old_problem_method :problem method
    def problem_method
      #guerilla code goes here!
    end
  end
end
class ProblemClass
  include MongoMapperExtensions::ProblemClassExtensions
end