新しいRailsプロジェクトで先延ばしを克服する方法

rails new を実行した直後、次に何をすればいいのか分からなくなった経験はありませんか?どこから手をつけるべきか。すべてを1つのアプリケーションに書くべきか、それともサービス指向アーキテクチャ(SOA)を採用すべきか。RSpecを学ぶのに良いタイミングなのか。まずデータモデルをすべて設計すべきか、それとも少数の機能をエンドツーエンドで動かすべきか。プロジェクト開始時には決めなければならないことが山ほどあり、迷って先延ばしをしてしまい、フラストレーションを感じたままアプリを完成させられない——そんなことは決して珍しくありません。

この問題は非常によくあるものです。原因は、情報が最も少ない段階で、あまりにも多くの選択を迫られることにあります。

Convention over Decision Making(規約による意思決定の削減)

Railsの原則の中で私が最も好きなのは「Convention over Configuration(設定より規約)」です。Rails以前の私は、ファイルをどこに置くべきか、データベースのテーブル名をどう付けるか、それらをオブジェクトにどうマッピングするかといった、些細で意味のない決断に悩まされ続けていました。方向性を選ぶのに費やす時間の方が、後で間違いだと気づいて方針を修正するのに必要な時間よりも長かったのです。

新しいプロジェクトを始めるときに直面する決断の多くも、これと同じ種類のものです。しかし、書籍やブログ、スタイルガイドから規約を借りてくれば、こうした決断を置き換えることができます。そうすることで、時間とストレス、そして無意味な議論から解放され、多くの時間を節約できるでしょう。

私が新しいアプリを始めるときに従っている規約をいくつか紹介します。

• まずは少数の完全な機能から始める

  アプリは最初から、思いつくすべてを実装する必要はありません。小さく、シンプルに始めましょう。絶対になくせない1〜2個の機能を見極めて、そこにすべての注意を向けます。そして、それらを本当に丁寧に作り込むのです。他の機能は必要になってから追加すれば十分です。おそらくYAGNI(「それは今は要らない」の原則)に従うことになります。しかも通常、自分自身が必要だと思うものは、顧客が必要だと考えるものとはまったく違う、ということが分かるはずです。

• まずは単一のアプリケーションから始める

  巨大なモノリシックアプリ(通称モノレール)になるのを避けたい気持ちは分かります。RailsConfでも、SOAこそが長期的にRailsアプリを保守可能に保つ最良の方法だ、という発表が何度も行われてきました。だからといって、アプリのどの部分を独立させられるかを見極めて、それぞれにサービスを構築すべきなのでしょうか?

  SOAは大規模で複雑なアプリを分割するには優れた手法です。しかし同時に、膨大な苦痛をもたらします。サービスの構築・保守・監視にかかる苦痛が、モノリシックなRailsアプリで作業する苦痛を上回らない限り、やる価値はありません。まだアプリの開発を始めてもいない段階であれば、その苦痛を感じていないはずです。だからこそ、まずは1つのアプリから始めましょう。

• 使い慣れたスタックから始める

  まだスタックに詳しくないのであれば、「Omakase(お任せ)スタック」を使えばいいでしょう。いずれにしても、使ったことのないテストフレームワークをRailsと統合するのに半日を費やしたり、VCRとWebMockのバージョン競合と格闘したり、テストが落ちたときにそれが自分のせいなのかresque_unitのせいなのか判別したりしたくはないはずです。新しいライブラリを試したいなら、後からいつでも追加できます(おもちゃのプロジェクトで試してみるのも良いでしょう)。

リリースは簡単ではありません。アプリを完成させたいなら、少しでも有利になる要素をひたすら集める必要があります。だからこそ、小さく、シンプルに、そして知っているもので始めるのです。

規約は常に完璧とは限りません。しかし、始めるための助けにはなります。そして、始めることが一番難しいのです。

次はどうする?

あなたのプロジェクトでは、どんな規約に従っていますか?また、どの機能やテストから着手すべきかは、どう判断していますか?私の考えは次回共有しますが、ぜひあなたの意見も聞かせてください。