モンキーパッチは良い開発方法ですか? たとえば、gem をフォークしてフォークされたプロジェクトにパッチを作成するのではなく、いつモンキーパッチを適用する必要がありますか?
2 に答える
一般に、モンキー パッチは決して良い方法ではありません。ただし、アプリケーションとは異なる非常に特殊な場合によく使用します。それ以外の場合はすべて、gem またはプラグインをフォークして、フォークした gem をアプリケーションの gems フォルダーに直接インストールすることをお勧めします。
また、いくつかのクラスにモンキー パッチを適用して、別のアプリケーションで再利用するためにいくつかの標準クラスに特別な目的の動作を挿入するいくつかのツール モジュールもありますが、これらはまだ一般に役立たないほど特別なものであるか、作成するのは実行不可能です。フォーク。
したがって、最終的には専門化と互換性の決定になります。モンキー パッチを適用すると、プロジェクトで使用する可能性のある他のプラグインや gem の予想される動作が損なわれる可能性が高いことに常に注意してください。これは、稼働中のアプリケーション エコシステム (または、Rails やその依存関係などの外部サポート エコシステム) のコンポーネントを更新すると、さらに差し迫ったものになる可能性があります。
責任あるダックパンチを実践すれば、gem のプロジェクト固有のローカルコピーと同じくらい簡単にサポートできます。どちらのソリューションでもアップグレードの問題を文書化するあなたの勤勉さに完全に依存します。あなたやサポート開発者が、1 年後にベンダー/gems でその gem を無謀に置き換えることはないだろうと言うのは簡単ですが、それは起こります。プロジェクトをフォークし、ローカルでパッチを適用し、プル リクエストを送信して、メインの gem に戻すことが理想的な状況です。
このルートを選択した場合でも、アヒルのパンチに関するいくつかのルールに固執する必要があります。
- パッチは、あからさまにわかりやすい場所に配置する必要があります。lib/[gem_name]_extensions.rb は、サポート開発者が欠陥をチェックするときに最初に確認する場所です。
- パッチには、それに関する大量のドキュメントが必要です。潜在的なアップグレードの悪夢について概説する必要があります。
- パッチは、元のモジュール/クラス ActiveSupport スタイルに含まれる別のモジュールで実行する必要があります。これにより、サポート開発者は problem_method.ancestors を呼び出して、進行中のモンキーパッチを確認できます。
これは、(楽しみとゲームのために) 古いメソッドを保持し、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