新しいRailsプロジェクトで先延ばしを打ち負かす方法

設定より規約は私のお気に入りのRailsの原則です。 Railsが登場する前は、ファイルを配置する場所、データベーステーブルに名前を付ける方法、オブジェクトにマップする方法、その他の意味のない小さな決定がたくさんありました。後で自分が間違っていることに気付いた場合に気が変わった場合よりも、方向を選択するのに多くの時間を費やしました。

新しいプロジェクトを始めるときに直面する多くの決定は、このようなものになります。ただし、コンベンションを借りれば、これらの決定を置き換えることができます。 本、ブログ、またはスタイルガイドから。そして、あなたは自分自身に多くの時間、ストレス、そして無意味な議論を節約するでしょう。

新しいアプリを起動するときに従う規則は次のとおりです。

• いくつかの完全な機能から始めます。

  アプリは、考えられるすべてのことをすぐに実行する必要はありません。小さく始めて、簡単に始めましょう。なくてはならない1つか2つの機能を見つけ出し、最初にそれらにすべての注意を向けます。それらを本当にうまく構築します。必要に応じて、後で他のものを追加できます。しかし、おそらく、YAGNI。 （そして、あなたは通常、あなたが 必要なものは顧客とはまったく異なると思います 必要だと思います。

• 単一のアプリから始めます。

  モノレールの建設は避けたいと思います。そして、RailsConfは、SOAがRailsアプリを長期的に保守可能に保つための最良の方法である方法について話します。アプリのどの部分を独立させることができるかを理解し、各部分のサービスを構築する必要がありますか？

  SOAは、大規模で複雑なアプリを分解するための優れた方法です。ただし、トンが追加されます 苦痛の問題であり、サービスの構築、保守、監視の苦痛がモノリシックRailsアプリでの作業の苦痛を上回らない限り、それは行う価値がありません。また、開始していない場合 まだアプリを書いていても、それほど苦痛は感じていません。したがって、1つのアプリから始めます。

• 以前に使用したスタックから始めます。

  スタックがまだわからない場合は、おまかせスタックを使用してください。ただし、いずれにしても、これまで使用したことのないテストフレームワークをRailsと統合するのに半日を費やしたくはありません。 VCRとWebMockの間のバージョンの競合と戦う必要はありません。テストのクラッシュが自分のせいなのか、resque_unitのせいなのかを把握する必要はありません。新しいライブラリを試してみたい場合は、後でいつでも追加できます（またはおもちゃのプロジェクトで試してみてください）。

発送は大変です。あなたがあなたのアプリを完成させたいならば、あなたはあなたが得ることができるすべての利点のためにこすり落とさなければなりません。ですから、小さく始め、単純に始め、そしてあなたが知っていることから始めましょう。

コンベンションは必ずしも完璧ではないかもしれませんが、始めるのに役立ちます。そして、始めるのが最も難しい部分です。

次は何ですか？

プロジェクトではどのような慣習に従いますか？また、どの機能またはテストから開始する必要があるかをどのように決定しますか？次回は私の考えを共有しますが、あなたの考えをいくつか聞いてみたいです。