gsa*_*kis 7 language-agnostic oop patch monkeypatching
我正在和一位同事谈论我们使用的某个包的一个意外/不期望的行为.尽管我们有一个简单的解决方法(或至少是解决方法)而没有任何明显的副作用,但他强烈建议通过硬修补并在上游发布补丁来扩展相关代码,希望将来某些时候可以接受.实际上,我们针对在每个新构建上自动应用的多个软件包的特定版本维护补丁.主要论点是,这是正确的做法,而不是"丑陋"的解决方法或脆弱的猴子补丁.另一方面,我赞成实用性而非纯度,我的一般经验法则是"无补丁">"猴子补丁">"硬补丁",至少除了(关键)错误修复之外的其他任何东西.
所以我想知道是否就什么时候(硬)补丁,猴子补丁或只是尝试解决一个不完全符合人们想要的第三方软件包达成共识.它是否主要与补丁的原因(例如修复错误,修改行为,添加缺少的功能),给定的包(大小,复杂性,成熟度,开发人员响应性),其他或没有一般规则和一个应根据具体情况决定？
在我看来：
如果“意外/不期望的行为”！= bug，则将指示“monkeypatching”（或“duckpunching”）。
如果您认为这是库中的错误，则进行硬修补并将补丁推向上游是有意义的。
如果我理解您对“解决办法”的定义是增加应用程序的复杂性以补偿库行为，那么我不得不说猴子补丁绝对是一个更好的主意。
我的 0.2 比索。