経験豊富なルビー開発者であり、人気のあるRuby Object Mapperの著者の1人であるPiotr Solnicaによる記事の翻訳に注目してください。 通常、翻訳者は著者の立場を共有します。




今日、私は再び疲れて、役に立たないと感じています。 そして、そのような感情が私を訪れたのはこれが初めてではありません。 通常、私はツイッターで「スチームをやめ」、フォロワーを失い、落ち着いて仕事を続けます。



しかし今日、私は自分の否定的な感情を建設的なものに燃やしたいと思っています。 私は通常、ルビーのエコシステムのいくつかの側面について、特にRails開発者の質問に対する簡単な答えを定式化できないことについて、ツイッターで泣いています。 主に時間の不足と、twitterは長時間の会話に最適な場所ではないためです。




この記事は、特にモンキーパッチの何が悪いのか、そして一般的にはレール開発のアプローチを定式化しようとする試みです。

モンキーパッチで角を切る

昨日、 Enumerable＃ pluckを追加するActiveSupportのプルリクエストに気付きました-そしてそれは受け入れられました。 どうして？ これは便利な機能です-追加してみましょう。 さらに、 ActiveRecordにはそのようなメソッドがあります 。すべてのEnumerableに追加しないでください。 便利です！



Rails開発者は、モンキーパッチを使用して次のようなことを行うことに気付きません。











タスクがあります。 青色の電気テープを貼って問題を解決できるのであれば、なぜ複雑なソリューションを探して使用するのか。 飛行機が着陸したので、この素晴らしい修復方法の著者は、青い電気テープがその特定のタスクに対する優れた解決策であると安全に言うことができます（実際、当然、青い電気テープはありませんが、わずかに異なるものがあります。画像は例示のみを目的としています）。




これはまさにモンキーパッチを使用して行うことです。角を切って、これが良い解決策であると確信します。

現在のニーズを満たすことは、実際の問題を解決するものではありません。

Rubyでmonkey-patchを使用するのは非常に簡単なので、この言語では一瞬立ち止まって考える機会さえ与えられません。 なぜこれをしているのですか？ どのような問題を解決しようとしていますか？ このモンキーパッチは、具体的にどのようなタスクを解決しますか？ このタスクは、正しく理解された方法で解決できる大きなタスクの一部ですか？ または、それは私のアプリケーションのロジックに関連するある種のローカルタスクであり、その解決策は私のアプリケーションの範囲を離れるべきではありませんか？



Enumerable＃pluckは、指定されたキーによってソースコレクションから選択された値を含むコレクションを返します 。これは便利な機能です。 問題は、この方法だけでは実用的な問題を解決できないことです。 monkey-patchは、データを変換して複雑さを分離するという特定のタスクを解決する代わりに、コードの高度な複雑さの一部を担います。そのため、この複雑さはこのコードに沿って忍び寄り始めます。




プラックよりももっと複雑なことをする必要がある場合はどうでしょうか？ Railsに感染した開発者が最初に考えるのは、モンキーパッチです。 このような開発者は、 Rubyでのデータ変換に対する私のアプローチを批判し、適切に作成されたモンキーパッチがよりエレガントなコードにつながると主張しています。



プロジェクトの複雑さに対処する唯一の方法は、ローカルの問題を切り分けて簡単な方法で解決することです。 monkey-patchを使用すると、開発者が混乱し、コードの凝集度が高まります。



必要ありません。 だから する。

これはどのように影響しますか？

この猿パッチの使用は、私たちの生態系にdamage大な被害をもたらすと考えています。 初心者を含む多くの開発者は、これがRubyの実用的な開発タスクに対処する必要があることを完全に確信しています。



もちろん、これは問題を解決する方法です。 しかし、これは良い方法ですか？ 私はそれを疑います。 いいえ、そうではありません。 これは悪い方法です。 そして、これは多くのルビーライブラリがあまりにも貧弱に書かれている主な理由の一つです：モンキーパッチの使用はインタラクションインターフェースの品質要件を下げます。 モンキーパッチを使用できる場合-なぜライブラリを拡張するためのインターフェイスを開発する必要があるのですか？




Railsであるその山の猿パッチの上にシステムを開発し続けることはできません。 これにより、行っている変更に対する自信が減り、コードが複雑になり、実行時にコードにパッチを当てるという悪質なプラクティスが開発者に伝わり、コードが実際に解決するタスクを理解することが難しくなります-インターフェースの競合、デバッグの困難などの特定のケースを含め、リストが延々と続く他の人がランタイムなどでコードを変更したためです。



先週、 ActiveSupportのObject＃with_optionsにより開発者は多くの時間を失いました（正確には2人の開発者。何が起きているのか理解できなかったので、私の助けを求めました）。 ActiveSupportでObject＃tryを発見するだけで、コードの奇妙な動作をデバッグすることで「たくさんの楽しみ」が得られました。これは、独自のtryメソッドを完全に異なるセマンティクスに置き換えました。 しかし、Railsがurl_helperでこれらのメソッドを使用しているという理由だけで、 NilClass＃to_paramおよびTrueClass＃to_paramメソッドを追加するこのモンキーパッチについてはどうでしょうか。 これらのすべてが「私の一日を作った」というのは一度きりではなく、そのたびに何時間もデバッグする必要がありました。 そして私を信じて、私だけではありません。

RailsはRubyを殺すかもしれない

2009年、ボブおじさん（ロバートマーティン）は、Rails Confで「Smalltalkを殺したことでRubyを殺すことができる」という報告を行いました。 要約：「混乱させるのは簡単すぎた」。



考えてみてください。 Railsはその混乱の大きな山、猿パッチ山、ニーズに合わせてRubyを修正するためのフレームワークです。 私の友人が言ったように、「レールズは自分自身をツールチェーンの主要な部分と考えています。」 とても気づいた。 その結果、破損したエコシステムと、それをますます破損するように訓練された世代の開発者がいます。




皮肉なことに、Ruby開発者の99％がRailsのためにRuby開発者になったということです（これが議論中の問題にどのように関係するのか、私にはよくわかりません）。 今何をしますか？ Railsを賞賛してください。私たちの多くはこのフレームワークのおかげで開発者になり、現在その欠陥を見ていますか？



多くの優秀な開発者がRubyの使用を停止しているか、すでに停止しているため、RailsはRubyを殺す可能性があります。 私はそれらの多くを知っており、私たちのコミュニティの損失を深く後悔しています。 誰かがツイッターで「何人かの専門家が逃げても悪いことは起こらない」と言った。 しかし、技術に重大な欠陥があり、専門家が使用をやめた場合、コンサバトリーに何か問題があるのでしょうか？