技術部の牧本です。 今日はモンキーパッチの話をします。
モンキーパッチとは何か
そもそもモンキーパッチ (monkey patch) とは何でしょうか? 端的に言えば、言語の組み込みクラスやライブラリ、その他外部ライブラリの挙動を、動的に拡張する仕組みをモンキーパッチと呼びます。 *1
例えば、Ruby のモンキーパッチのすごく単純な例として以下のようなものがあります。
moduleNilClassExtensiondefempty?trueendendNilClass.prepend(NilClassExtension)
インスタンスが空であるかどうかを判定するメソッドとしての #empty?は Stringや Arrayなど様々なクラスに存在しますが、 nilを唯一のインスタンスとする NilClassには本来は存在しません。
このモンキーパッチを導入することで、通常はメソッドがないことによる例外が発するはずの nil.empty?というメソッド呼び出しが、 trueを返すようになります
さて、このようなパッチが読み込まれたシステムでは、予想外の挙動が起きます。
例えば、 method_missingを用いてフォールバックするようにしているライブラリがあるとすると、 nilは本来 #empty?メソッドを受け取れないはずが、パッチが存在するためにフォールバックせず、挙動が変わってしまいます。
ここで例に挙げた NilClassに #empty?メソッドを追加するモンキーパッチは、あとで述べるように、モンキーパッチとしては行儀の悪い部類です。
しかし、このパッチは、実はかつて実際にクックパッドに存在していたものです。
クックパッドの中心となるアプリケーションのレポジトリは最初に作られてから10年弱が経過しており、歴史的経緯から様々なモンキーパッチが存在します。 われわれは、これらのモンキーパッチとうまくやる方法を考えていく必要があります。
そこから得られた知見をもとに、本稿では Ruby on Rails アプリケーションにおける、モンキーパッチの当て方、そして、モンキーパッチの外し方について紹介します。
モンキーパッチの当て方
さて、あなたが Ruby でアプリケーションを書いていて、ライブラリなどの標準の挙動を変えるためにモンキーパッチを導入したいと考えたとします。 その際、まずは最初の原則を当てはめましょう。
最初の原則 - モンキーパッチを使わない
まず、本当にモンキーパッチを当てる必要があるかを考えましょう。 それが何らかの不具合に対する対策だとしたら、ライブラリを最新バージョンにアップデートすることで対応できませんか。 発想がモンキーパッチになってはいけません。 何らかの組み込みクラスの挙動を変えたい場合、クラスそのものを拡張する以外の方法は取れないか考慮するべきです。
冒頭述べた NilClass#empty?について言うならば、 nilが入る可能性がある変数に対し、 var.empty?と呼んだときに trueが返ってほしいのは理解できなくはないですが、Rails アプリケーションでは var.blank?というほぼ同等の代替手段があるので回避できるはずでした。
そういう観点ではこのモンキーパッチは入れるべきものではなかったと言えます。
それでもモンキーパッチを当てたいとき
とは言え、モンキーパッチを使わざるを得ない場面が起きるかも知れません。 よくある例として、外部のライブラリになんらかのバグがあるがそれが修正されたバージョンがリリースされていない場合、または、ライブラリのアップデートによる影響範囲が大きく別途検証が必要なためにすぐにアップデートできない場合などです。
以上のような理由でモンキーパッチを当てなければならない場合、最大限パッチをコントロールする必要があります。
パッチを隔離する
モンキーパッチを導入することを決めたとき、まず行なうべきはモンキーパッチ用のディレクトリを作成することです。 これによって、他のモジュールやクラスに影響を与えるコードを一箇所に集めることで一覧性を高め、読み込みのタイミングを統一します。
クックパッドでは #{Rails.root}/lib/monkey_patchesというディレクトリがよく使われており、このディレクトリをイニシャライザで requireしています。
# config/initializers/000_monkey_patches.rbDir[Rails.root.join('lib/monkey_patches/**/*.rb')].sort.each do |file| require file end
アプリケーションから見えるインターフェースを変えない
モンキーパッチを当てる場合に気をつけることの一つに、パッチを当てたことによってアプリケーションコード (モンキーパッチを当てたライブラリを使う側のコード、 Rails の場合は appディレクトリ以下にあるコードなど) を変更させるべきではないうものがあります。
つまり、たとえライブラリにパッチを当てたとしても、新しいインターフェースを増やしたり、既存のインターフェースを変更させないということです。
これによって、モンキーパッチを外すときの労力がかなり下がります。
例えば、最初に論じた NilClassに #empty?を追加するというパッチは、この原則に則しておらず、実際にパッチを除去する際に大きな労力を要しました。
パッチが不要になったときに外せるようにする
さて、影響範囲を最小限にするという観点では、パッチが不要になるタイミングで適切にキャッチアップしてパッチを削除することができるようになるべきです。
最低限やるべきは、なぜそのパッチを導入することになったかをコメントとして残すことです。 さらに、どういう状態になればパッチを外して良いかまで明記されていると、将来の自分やチームメンバーがそのパッチを外せるかどうかで悩むことを防げます。
より良い方法は、パッチが不要になったら開発者が自動的に気づけるようにすることです。 例えば、ライブラリの特定のバージョンの挙動に依存してパッチを当てざるを得なくなった場合、以下のようにライブラリをアップデートしたら例外が発生するようにして、もしパッチを消し忘れてもテスト実行時などに気づけるようにします。 *2
# lib/monkey_patches/nanika_ext.rbrequire'nanika/version'unlessNanika::VERSION == "2.2.0"raise"Consider removing this patch"endmoduleNanikaMonkeyPatch# monkey patches go here...endNanika.prepend(NanikaMonkeyPatch)
このように、大規模なアプリケーションにモンキーパッチを当てる際には細心の配慮をもって対応する必要があります。
モンキーパッチの外し方
さて、当てたモンキーパッチはいずれは外されなければなりません。 次に、どのようにモンキーパッチを外すのかについて論じていきます。
モンキーパッチを当てるときに注意を払えば、開発者はどのタイミングで外せるかを気づくことができるし、安全に外せるようになっているはずです。
モンキーパッチを外す作業は、外部ライブラリのアップデートや内部ライブラリの挙動を変更した場合の対応とほぼ同じです。 つまり、影響範囲を調べて、動作確認をして、問題なければリリースするという手順を踏みます。
先述の通り、ライブラリのインターフェースはパッチを当てた場合も外した場合も同じであることが期待されるので、基本的にアプリケーションのコードを変更する必要はないはずです。 しかしながら、実際はパッチによる副作用によって思わぬ場所で不具合が発生するかも知れないので、一度入れたパッチは細心の注意を払って外すべきです。
まとめ
本稿では、 Ruby on Rails アプリケーションにおけるモンキーパッチの当て方について記述しました。 先に述べたように、モンキーパッチを可能な限り使わず、使うときは最小限の影響範囲に留めて、なるべくふつうの Ruby、ふつうの Rails を使うことがアプリケーションの寿命を延ばす秘訣であると考えます。