ruby-on-rails - Rails 中的猴子补丁

Question

猴子补丁是一种好的开发实践吗？我什么时候应该进行monkeypatch，而不是说，fork一个gem并在分叉的项目上制作补丁？

Answer 1

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

我还有一些工具模块，它们对一些类进行修补，以将特殊用途的行为注入一些标准类中，以便在不同的应用程序中重用——但这些仍然足够特殊，对公众没有用处，或者创建它是不可行的叉子。

所以最终它是专业化和兼容性的决定。永远记住，猴子补丁更有可能破坏您可能在项目中使用的其他插件或 gem 的预期行为。在更新您的工作应用程序生态系统（或外部支持生态系统，如 Rails 及其依赖项）中的组件后，这可能会变得更加紧迫。

Answer 2

如果您练习负责任的打鸭式，它可以像支持项目特定的本地 gem 副本一样容易。这完全取决于您对任一解决方案的升级问题的记录。很容易说，您或支持开发人员不会在一年后鲁莽地替换 vendor/gems 中的那个 gem，但它确实发生了。分叉项目，在本地修补它，然后提交拉取请求并将其重新放入主 gem 是理想的情况。

如果你选择这条路线，你需要遵守一些关于打鸭的规则：

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

这将是一种保留旧方法（用于娱乐和游戏）并允许您使用 question_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