Thoughtworks における Ruby

Ruby は正しい選択だったか？

過去の 41 件のプロジェクトを振り返るとき、おそらく最も重要な質問は、Ruby プラットフォームが正しい選択だったかどうかです。その質問に答える 1 つの方法は、プロジェクトの技術責任者に、今にして思えば、その選択が正しかったと思うかどうかを尋ねることです。

図 4：このプロジェクトでは、Ruby は適切なプラットフォームの選択でしたか？

図 4 が示すように、選択に対する非常に前向きな 36 対 5 の支持票がありました。技術責任者のグループとして、私たちは通常、技術的な選択に不満がある場合はそれを表明することをためらいません。したがって、これは、Ruby プラットフォームが妥当な選択肢として実行可能であるという断固たる声明だと考えています。

私は、後悔した 5 つのプロジェクトについてもう少し詳しく調べました。最初に目立ったのは、5 つのケースのうち 4 つで、責任者が Ruby を使用することが代替案よりも悪い選択ではなかったと感じたことでした。Ruby の相対的な珍しさとは、Ruby を使用すると代替案よりもメリットがあるように感じる必要があることを意味します。Ruby がより広く使用されているオプションと同じであれば、珍しい技術を導入する価値はありません。5 つのうち 4 つは、Ruby があまり適していない他の技術との統合による問題も報告しました。たとえば、.NET ツールは .NET 技術との統合性が高い傾向があります。また、2 つのプロジェクトが報告したテーマは、クライアント組織の人が Ruby やその他の動的言語に反対していたという社会的な問題でした。より悪いプロジェクトの 1 つは、これらの社会的な問題を示していました。つまり、IT 組織が Ruby に徹底的に抵抗していました（この場合、ビジネススポンサーは Ruby のファンでした）。

実際、ソフトウェアプロジェクトで Ruby を使用する際の注意点についてさらに質問したところ、明確な答えは社会的な問題に関するものだけでした。Ruby は私たちのソフトウェア開発業務で一般的に受け入れられるか推奨されていましたが、それを避ける最大の兆候は、クライアントからの社会的な抵抗でした。

Ruby はより生産的か？

プロジェクトで Ruby を使用する理由について質問すると、最も一般的な答えは生産性の向上です。初期の指標の 1 つは、Ruby が生産性を 1 桁向上させる可能性があることを示唆するプロジェクトの評価でした。

その結果、プロジェクトの技術責任者を調査し、生産性について尋ねることが明らかであるように思われました。Ruby は生産性を向上させたか、もしそうなら、どの程度向上したのかということです。私は、これを知っている最も生産的な方法で実施した主流（Java または .NET）プロジェクトと比較するように依頼しました。

図 5：このプロジェクトで Ruby はどの程度生産性を向上させましたか？（知っている限りで最高の主流ツールと比較して。）

この結果は割り引いて考えるべきです。結局のところ、ソフトウェアの生産性を客観的に測る方法はありません。これは各プロジェクトの技術責任者からの主観的で定性的な評価に過ぎません（すべてのプロジェクトから回答を得られたわけではありません）。しかし、それでも生産性が実際に向上していることを示唆するものです。

この示唆は、人員配置の観点からも裏付けられます。アトランタオフィスを管理するスコット・コンリー氏は、Rubyプロジェクトが始動すると、他の技術の場合よりも要件準備に重点を置く人員が50%増える必要があると報告しています。

一つわかったことは、これらの生産性の向上はすぐには現れないということです。新しいRubyチームの進捗が遅いことに最初の数週間で人々が警戒したという話を何度か聞きました。これは私が「改善の谷」と呼んでいるものの結果です。Rubyチームがプラットフォームの使い方を習得するには時間がかかり、その間は予想よりも遅くなるでしょう。

改善の谷はよく見られる現象であり、一般的な緩和策は、経験豊富な人員をチームに加えることです。しかし、私たちの経験では、ここで最も重要なのは、特にRubyの経験ではなく、Rubyのようなメタプログラミング機能をサポートする動的言語の経験です。スコット・コンリー氏が言うように、違いは効率リスクとデリバリーリスクの間にあります。動的言語の経験はあってもRubyの経験が少ないチームは最初は遅くなるでしょう（効率リスク）が、動的言語の経験が全くないチームは、全体的なデリバリーを危険にさらす可能性のある複雑なコードベースを作成してしまう可能性があります。

Ruby は遅いのか？

一言で言えば「はい」です。ネット上でベンチマークを検索すれば、スクリプト言語の標準から見ても、Rubyが亀であるという調査が多数見つかるでしょう。

しかし、全体として、これは私たちにとって無関係でした。私たちのRubyの利用例のほとんどは、データベースをバックエンドにしたウェブサイトの構築です。Rubyや他の技術を使って、このようなプロジェクトを数十年にわたって数多く見てきましたが、ほとんどすべてのプロジェクトでパフォーマンスの問題に取り組む時間があり、ほとんどの場合、これらのパフォーマンスの問題はデータベースアクセスです。人々は、処理コードをチューニングするのではなく、SQLをチューニングすることに時間を費やしています。したがって、ほとんどのアプリケーションはI/Oバウンドであるため、処理に遅い言語を使用しても、システム全体のパフォーマンスに目立った影響はありません。

上記の段落では、よくある専門家の逃げ言葉を使っていることに気づくでしょう。ほとんどすべてのプロジェクトがI/Oバウンドですが、時折例外に出くわします。その興味深い例がMingleです。Mingleは多くの点で異例です。非常に動的な表示のため、パフォーマンスを向上させるためにページキャッシュを使用できず、すぐにほとんどのWebアプリケーションとは異なります。その結果、I/Oバウンドではなく、良好なパフォーマンスを得るには、多くの人が予想するよりも多くのハードウェアが必要です（20〜40人のチームをサポートするには、4コア、2GBのメモリを搭載したマシンが必要です）。

しかし、Mingleチームは依然としてRubyを使用したことが正しい選択だったと感じています。Mingleチームは多くの機能を非常に迅速に構築しており、Rubyから得られた生産性の向上は、最終製品に対するハードウェアの要求の高さに見合うものだと感じています。多くのことと同じように、これはハードウェアと生産性のトレードオフであり、コンピューティングにおける最も古くからのトレードオフの一つです。各チームはどちらが重要かを考える必要があります。ここで良いニュースは、Mingleには優れた水平スケーラビリティがあるということです（より多くのプロセッサを投入すると、比例して優れたパフォーマンスが得られます）。ハードウェアのスケーラビリティは、ハードウェアコストが下がり続けるこれらの状況では、しばしば最も価値のあるものとなります。

再度強調する必要があります。ほとんどのプロジェクトはI/Oバウンドであるため、ほとんどのプロジェクトではRubyの速度は無関係です。Mingleは例外であり、一般的なケースではありません。

Ruby のコードベースは理解しにくいのか？

Rubyについてよく聞かれる懸念は、動的な型付け、メタプログラミングのサポート、ツールの欠如により、追跡が困難なコードベースになる可能性があるということです。一般的に、これは実際には私たちにとって問題ではありませんでした。私が聞いている話では、同じ機能に対して書くコードがはるかに少ないということは、主流の言語よりもコードをきれいに保ちやすいということです。

ただし、私たちの状況を覚えておくことが重要です。Thoughtworksの開発者は、能力の点で平均をはるかに上回る傾向があり、アジャイル開発のような規律を重んじるアプローチにも熱心です。私たちはテストを高く評価しており（これはRubyコミュニティ全般に当てはまります）、これらのテストはコードベースを明確に保つ上で大きな役割を果たしています。したがって、私たちの経験が能力や規律の低い開発者にも当てはまるかどうかはわかりません（他の言語のツールや相対的な制御でも、ひどいコードを見かけるのを防ぐことはできません。したがって、ひどいRubyコードベースがそれほどひどくなるかどうかは疑問です）。

メタプログラミングに対する態度の一般的な推移が見られます。

図6：メタプログラミングに関する感情の推移

• 怖いし悪い：人々はメタプログラミングを警戒し、あまり使いません。
• 怖いけど良い：人々はメタプログラミングの価値を認識し始めますが、まだ使用することに抵抗があります。
• 簡単で良い：人々が慣れるにつれて使いすぎてしまい、コードベースを複雑にする可能性があります。
• 簡単で悪い：人々はメタプログラミングを警戒し、少量で非常に役立つことに気づきます。

最終的に、この種の技術で私が最も気に入っているのは、処方薬のようなものだという例えです。少量では非常に価値がありますが、過剰摂取しないように注意する必要があります。

多くのことと同じように、経験は、このカーブをより迅速に乗り越えることができるため、ここでは非常に役立ちます。特に、この採用カーブ、特に過剰使用を予想することが重要です。新しいことを学ぶとき、ある段階で過剰に使用することは一般的です。なぜなら、一線を越えなければ、その線がどこにあるのかを知ることは困難だからです。また、サンドボックスを構築してみることも役立ちます。これは、人々がメタプログラミングをやりすぎるための、比較的隔離されたコードベースの領域です。適切なサンドボックスがあれば、後で過剰使用を元に戻すのが容易になります。

Ruby は実行可能なプラットフォームか？

これらのすべての質問は、私たちにとっての重要な質問、つまりRuby（およびRails）が私たちとクライアントにとって実行可能なプラットフォームであるかどうかに集約されます。これまでのところ、答えは「はい」という力強いものです。それは目に見える生産性の向上を提供し、クライアントにより迅速に対応し、より優れたソフトウェアをより迅速に作成できるようにします。これは、すべての状況に適した選択であるという意味ではありません。開発プラットフォームを選択することは決して簡単な選択ではなく、特に通常は技術的な選択というよりも社会的な選択であるためです。しかし、結論としては、Rubyは検討に値する選択肢であり、このツールをツールキットに入れておきたいと思えるほど価値があるということです。

ここで興味深い副次的な質問は、他のあまり一般的でない言語の役割です。Groovy、F#、Python、Smalltalkなどを使用する必要があるのでしょうか？Rubyで見るのと同じトレードオフの多くが、これらの他の言語にも当てはまるとしても驚きません。近い将来、これらのいくつかがツールキットに追加されることを願っています。

また、これらの言語と主流のJava/C#オプションを使用する場合、どちらか一方を選ぶというわけではないことも強調する必要があります。私は常に、Java/C#のような言語を使用している開発チームは、さまざまなサポートタスクのためにスクリプト言語も使用すべきだと主張してきました。Rubyはこれに最適な選択肢であり、私たちのプロジェクトでこの組み合わせが増加しているのを見ています。JVMおよびCLRでのこれらの言語のサポートの増加に伴い、異なる強みを持つ異なる言語を混在させる機会が増えています。これは、ニール・フォードが「ポリグロットプログラミング」と呼んでいるアプローチです。

Active Record を用いたテスト

Rubyの使用を開始した当初、RailsのActive Recordデータベースレイヤーが存在する場合に、テストをどのように整理するのが最適かについての議論がありました。基本的な問題は、エンタープライズアプリケーションのパフォーマンスのほとんどがデータベースアクセスによって支配されるということです。テストダブルを使用することで、テストを大幅に高速化できることがわかりました。高速なテストは、テスト集約的な開発プロセスにとって非常に重要です。ケント・ベックは、10分未満の基本的なコミットビルドを推奨しています。最近では、ほとんどのプロジェクトがこれを達成しており、データベースダブルを使用することはそれを達成するための重要な部分です。

Active Recordの問題は、データベースアクセスコードとビジネスロジックを組み合わせることで、データベースダブルを作成することがかなり難しいことです。Mingleチームのこれに対する反応は、Railsがデータベースを密接にバインドしていることを受け入れ、すべてのコミットテストを実際のデータベースに対して実行することでした。

これとは反対の意見は、アトランタとジャージーチームによって最も強く主張されました。Rubyには、実行時にメソッドを再定義できる強力な機能があります。これを使用して、アクティブレコードクラスを取得し、そのクラスのデータベースアクセスメソッドをスタブとして再定義できます。チームは、これを支援するためにgem unitrecordを開始しました。

この3年間で、この議論で一般的に受け入れられる勝者は現れていません。Mingleチームは、約8分で実際のPostgresデータベースに対して数千のテストを実行しています（複数のコアを利用するためにテストを並列化しています）。アトランタとジャージーチームは、スタブを使用するとコミットテストが2分で実行されるのに対し、スタブなしでは8分かかることを価値があると考えています。トレードオフは、直接データベーステストのシンプルさと、スタブされたテストのより高速なコミットビルドとの間にあります。

両方のチームは、この議論におけるそれぞれの立場に概ね満足していますが、スタブの使用は、アトランタ/ジャージーチームにとって別の問題につながっています。チームがメソッドスタブの使用に慣れるにつれて、ますますそれを使用するようになり、テスト対象のメソッド以外のすべてのメソッドをスタブアウトするユニットテストの過剰使用という、避けられない状況に陥りました。ここで問題になるのは、ダブルを使用する場合によくあるように、もろいテストです。アプリケーションの動作を変更すると、古い動作を模倣している多くのダブルも変更する必要があります。この過剰使用により、両方のチームはスタブされたユニットテストから離れ、より多くのRailsスタイルの機能テストを直接データベースアクセスで使用するようになりました。

Active Record のリーク

人々が報告する一般的な状況は、SQLの操作に費やされる時間です。Active Recordは、プログラマーからのデータベースアクセスを隠すのに優れていますが、すべてを隠すわけではありません。本質的に抽象化が漏れています。その結果、人々はSQLを直接操作するのにかなりの時間を費やす必要があります。

この漏洩は、オブジェクト/リレーショナルマッピングフレームワークの一般的な機能です。ほとんど毎回、プロジェクトの人々と話すと、O/RマッピングフレームワークはSQLを約80〜90%の時間効率的に隠しますが、まともなパフォーマンスを得るためにはSQLを操作するのにいくらかの時間を費やす必要があると言われるでしょう。したがって、この点で、Active Recordは他のO/Rマッパーと実際には違いはありません。

実際、私が聞くコメントの1つは、Active Recordを使用すると、抽象化が綺麗に壊れるということです。DHHとチャットするとき、彼はリレーショナルデータベースを使用する開発者はSQLを操作する方法を知っているべきだと常に強調してきました。Active Recordは一般的なケースを簡略化しますが、より複雑なシナリオに到達し始めると、SQLを直接使用することを期待します。

O/R抽象化の漏洩を、これらのフレームワークに対する非難とは考えていません。これらのフレームワークの目的は、一般的なことをより簡単にできるようにすることで生産性を向上させることです。これにより、チームは本当に重要な少数のケースに注力できます。問題は、チームが抽象化が水密だと信じ込み、SQLの操作に全く努力しない場合にのみ発生します。これはよくある失敗ですが、O/Rフレームワークが正しく使用された場合の真の利点を放棄する理由にはなりません。

長時間実行されるリクエスト

よく見られる問題は、実行に時間がかかるタスクを引き受けたときにアプリケーションが混乱に陥ることです。安易に行うと、ウェブ リクエスト ハンドラーがリクエストを処理している間、非常に長い時間応答しなくなる可能性があります。

これはあらゆるヒューマンインターフェースにおいて非常に一般的な問題であり、一般的な解決策があります。それは、タスクをバックグラウンドプロセスまたはスレッドに引き渡すことです。リッチクライアントGUIアプリケーションでプログラミングをしたことがある人なら、このようなことをしたことがあるでしょう。ただし、この引き渡しと通信が適切に行われないと、問題が発生することがあります。

私が好んでおり、幸いなことにほとんどのThoughtWorkerが同意していると思われる方法は、アクターを使用することです。このモデルでは、ウェブ リクエスト ハンドラーは、長時間実行されるタスクをコマンドでラップし、キューに入れます。バックグラウンドアクターは、キューを監視し、キューからコマンドを取り出して実行し、完了したら人間とのやり取りを担当するアクターに通知します。通常、キューはデータベース内のテーブルとして始まり、必要に応じて実際のメッセージキューシステムに移行することがあります。

Active Recordの漏洩性と同様に、Railsアプリケーションに特有の問題であるから指摘するのではなく、あらゆる種類のアプリケーションで見られることだから指摘します。Railsを使用する多くの人がこのようなことが起こることを忘れがちであり、この種のパターンを使用する必要があるということを指摘しておきます。RailsはWebアプリケーションの反復的な部分をより簡単に、より迅速に実行できるようにすることがわかりましたが、より複雑なものは依然として残っています。

デプロイメント

Railsアプリケーションは構築が容易ですが、残念ながらデプロイが非常に面倒でした。いくつかのmongrelウェブサーバーのパックを使用するという一般的なシナリオは、せいぜい設定がやや面倒です。これは、rubyエクスペリエンスの他の部分のスムーズさとのコントラストによって、かなり際立っていました。

現在のコンセンサスは、Phusion Passengerがこれを非常に簡素化し、現在はMRIでの推奨デプロイアプローチであるということです。

私たちはデプロイにJRubyを使用することも強く支持してきました。JRubyを使用すると、標準のJava Web-Appスタックを使用できるため、多くの企業環境で対応がはるかに簡単になります。Mingleもこのアプローチを使用して、顧客向けのインストールを容易にしています。実際、Mingleチームはすべての開発をMRIで行っていますが、デプロイはJRubyで行っています。MRIの起動時間が速いため、開発が高速化されるためです。（JRubyではJVMの起動が必要で、これは明らかに遅いです。）

Gem の管理

Rubyには、サードパーティライブラリのインストールとアップグレードを簡単にするパッケージ管理システムであるRuby Gemsが含まれています。Railsにも、railsに対して同様のタスクを実行するプラグインがあります。これらは優れたツールですが、異なるバージョンの異なるライブラリが設定された場合、チームが混乱する可能性があります。

これに対処する方法はいくつかあります。最初のアプローチでは、すべてのサードパーティライブラリのソースコードのコピーを作成し、ソース管理にチェックインします。これにより、単純なチェックアウトで、すべてのライブラリの正しいバージョンがすべて取得されます。2番目のアプローチは、すべてのライブラリの正しいバージョンをダウンロードしてアクティブ化するスクリプトを使用することです。このスクリプトは、ソース管理で保持する必要があります。

同様に、ほとんどのチームはRailsのソース自体もコピーします。これにより、バグやその他の重要な問題を修正するために、Railsに直接パッチを適用できます。これらのパッチは、コアチームに送信できます。gitのような分散バージョン管理システムを使用することで、この管理が少し簡単になりました。過去にJavaアプリケーションサーバーをデコンパイルしてパッチを適用しなければならなかったときの記憶よりも、間違いなくはるかに簡単です。

アップデートの時間を設ける

一般的にRuby、特にRailsは急速に進歩しています。Railsシステムには頻繁なアップデートがあり、使用したい機能があります。Railsのアップデートの処理に時間をスケジュールし、計画プロセスに含める必要があることがわかりました。他のプラットフォームよりも重要ですが、良いニュースは、新しい機能が着実に提供されているということです。

Windows での開発

Rubyはunixの世界で生まれ、プラットフォームに集まったほとんどの人はディレクトリパスにスラッシュを使用します。windowsプラットフォームでrubyの実行、デプロイ、開発を行うことは可能ですが、それもかなり面倒です。私たちからの一般的なアドバイスは、すべての開発にunixプラットフォームを使用することです。Macが一般的に好まれていますが、他のFOSS Unixを使用している人もたくさんいます。

Iron Rubyが開発されるにつれて、この状況が変わることを願っています。基本Unix、JVM、またはCLR上でRubyアプリケーションをデプロイするオプションがあると便利でしょう。実際、これにより、Rubyは複数のプラットフォームでのランタイムサポートに非常に柔軟なオプションになるでしょう。また、メインラインの.NET言語と組み合わせて、.NETプロジェクトでRubyをスクリプト言語として使用できるようになります。