構成合意
Railsの初期のモットーの1つは、「あなたは美しくユニークなスノーフレークではありません。」 モットーは、個性を捨てることは些細な問題の解決を回避し、本当に重要な分野でより速く進歩することができるということでした。
データベース内の主キーがどの形式で記述されているかは誰が気にしますか？ これは、「id」、「postId」、「posts_id」または「pid」に関しては本当に重要ですか？ これは継続的な議論の価値ある決定ですか？ いや
Railsの使命の一部は、Webベースの情報システムの開発者が直面している繰り返し発生するソリューションの密集して成長しているジャングルのなたを振るうことです。 一度だけ行う必要があるこのような決定は数千ありますが、他の誰かがあなたのためにそれを行うことができれば、さらに良いことです。
構成に合意を渡すことで議論から解放されるだけでなく、より深い抽象化の成長のための豊かな分野も提供します。 personクラスのPersonクラスの依存関係を使用できる場合、同じ変換を使用して、has_many：peopleとして宣言された関連付けを表示して、Personクラスを検索できます。 良い取引の力は、幅広い用途で配当を支払うことです。
しかし、専門家の開発速度を上げることに加えて、この契約は初心者の入場基準も下げます。 Railsには非常に多くの慣習があり、初心者はそれを知る必要すらありませんが、彼は無知を利用することができます。 すべてがこのように機能する理由を知らなくても、優れたアプリケーションを作成できます。
フレームワークが厚いチュートリアルであり、新しいアプリケーションが白紙の場合、非常に困難です。 どこから始めればよいかを簡単に把握するには、多大な努力が必要です。 努力の半分は検索です-適切なスレッドを見つけることです。
すべてがどのように連携するかを理解すると、同じことが起こります。 変更ごとに明らかな次のステップがある場合、以前と同じまたは非常に類似したアプリケーションの多くの部分を再利用できます。 すべての場所とその場所にあるすべてのもの。 制約は、最も有能な心さえ解放します。
すべてと同様に、合意の力には落とし穴がないわけではありません。 Railsを使用すると、非常に簡単にすべてを行うことができますが、テンプレートのみを使用してアプリケーションのあらゆる側面を形成できると誤解されがちです。 しかし、ほとんどのアプリケーションでは、ユニークな特別な要素があります。 アプリケーション全体の5％または1％の場合もありますが、そのようなことが起こります。
最も難しいのは、合意の過程からいつ逸脱するかを理解することです。 この決定を正当化するほど深刻な理由はいつですか？ 美しくユニークなスノーフレークになるための前提条件のほとんどはまだ十分に考慮されておらず、Railsの使用を回避するコストは過小評価されていると断言します。 これですべてを注意深く学習するのに十分です。
メニューはおまかせ
レストランのメニューから何を選ぶべきかわからない場合、どのような決定を下しますか？ まあ、シェフがあなたのために選択をすることを許可すると、「良い」とは何かを理解する前に、彼はあなたを驚かせることができるでしょう。 これはおまかせです。 あなたからの専門知識を必要とせず、また選択時に盲目的な運に頼らないようにする、よく食べる方法。
プログラミングの場合、このプラクティスの利点は、他の誰かがスタックをまとめることができることです。 これは、構成契約から得られる利点と似ていますが、より高いレベルです。 構成契約は個々の構造の使用を最適化していますが、Omakaseはどの構造が存在し、どのように相互接続されているかについて取り組んでいます。
これは、利用可能なツールを選択する際にプログラマーが個々の決定を下すことを奨励する伝統と矛盾しています。
誰かが「あなたの仕事で最高のツールを使用してください」と言った瞬間に聞いたことがあるでしょう。 あまりにも初歩的な話なので、議論することすらできませんが、「最良のツール」を選択できるかどうかは基盤に依存するため、完全な自信を持って「最良」を判断できます。 見た目よりもはるかに複雑です。
これはレストランでの夕食と同様の問題です。 8つの料理から選択する方法、まあ、ライブラリまたはフレームワークの選択は、単独では機能しません。 両方の場合の目標は、夕方またはシステム全体を見ることです。
したがって、RoRでは、選択を減らし、個々のツールのプログラマーの個々の選択を、より多くのものに置き換えることを決定しました。誰にとっても最高のツールのセットです。 配当は大勢です：
- セキュリティは数字で表されます。ほとんどの人がデフォルトで同じ方法でRailsを使用する場合、一般的な経験があります。 これは、初心者が学習しやすくするために役立ちます。 これがコミュニケーションの基盤となります。 私たちは皆、昨夜7時に同じショーを見たので、次の日にそれについて話すことができます。 これは、コミュニティのより強い感覚に貢献します。
- 人々はツールの同じ基本セットを改善します。 Railsにはフルスタックフレームワークとして多くの可動部品があり、それらがどのように連携するかは、単独で行うことと同じくらい重要です。 ほとんどのソフトウェアの問題は、個々のコンポーネントではなく、それらの相互作用に起因しています。 さまざまな理由で構成およびクラッシュするコンポーネントの一般的な問題を軽減するために全員で作業を行うと、問題が少なくなります。
- 代替も可能ですが、必須ではありません。Railsはおまかせスタックですが、特定のフレームワークまたはライブラリを代替に置き換えることができます。 あなたはそれを必要としません。 これは、ツールのランダムなセットではなく、「ベストソリューション」の明確な個人パレットを開発するまで、これらの決定を先送りできることを意味します。
Railsに来て滞在する最も教育を受けた経験豊富なプログラマーでさえ、すべてのメニューの問題を気にすることはないでしょう（もしそうなら、彼らはおそらくRailsに縛られないでしょう）。 そのため、彼らは慎重に代替案を選択し、コミュニティとスタックを共有することでメンターからの脱却を楽しみます。