フレームワークとは？

docs.scrimba.com

小さなウェブアプリを構築していると想像してください。アカウント、フィード、設定ページなどです。あなたの独自のアイデアが画面に現れる前に、URLをページに変換するコード、データベースと通信するコード、パスワードを安全に保つコード、何かが変わったときに画面を再描画するコードが必要です。これらはすべてあなたのアプリの独自のアイデアではありません。すべてのアプリがこれらを必要とし、ほとんどはプロジェクトからプロジェクトへと同じです。

これらのすべての配管を自分で書くこともできます。実際、人々は長年の間そうしていました。それは遅く、微妙なバグが潜む場所であり、すべてのチームは同じ機械の少しずつ異なる、少しずつ壊れたバージョンで終わりました。フレームワークは蓄積された答えです。共有された配管で、一度書かれ、何千ものプロジェクトによって強化され、あなた自身のコードがどこに行くかを示す構造とともにパッケージされたものです。あなたのプロジェクトをあなたのものにする部分を構築し、フレームワークはすべてのプロジェクトが繰り返す部分を処理します。

フレームワークはウェブの話ではありません。プログラムが構築されるあらゆる場所に存在し、この章はあらゆる言語とあらゆる分野での考え方についてのものです。

フレームワークとは何か（そしてライブラリとは何か）

言葉は緩く使用されるため、実際に重要な区別をコードで示します。

// ライブラリ：あなたのコードが管理者で、必要に応じてライブラリを呼び出します。
const label = dateLibrary.format(order.createdAt, "MMM D");

// フレームワーク：フレームワークが管理者で、あなたが接続したコードを呼び出します。
export default function OrdersPage() {
  return listOfOrders();
}

最初の行はあなたが操舵しています。あなたのプログラムが実行され、1つのジョブのためにツールを借ります。2番目は種類が異なります。OrdersPageを自分で呼び出すことはありません。それを書いて、フレームワークが期待する場所に置き、フレームワークは適切な瞬間にそれを呼び出します。ここでは、訪問者が注文ページを開いたときです。

このフリップには名前があります。**制御の反転**です。ライブラリでは、あなたのコードはプログラムのフローを制御し、ヘルパーを借ります。フレームワークでは、フレームワークがフローを制御し、あなたのコードがそれが残した空白を埋めます。便利な略語：ライブラリを呼び出し、フレームワークがあなたを呼び出します。

同じ形状はプログラミングのあらゆる隅に現れます。Djangoはウェブリクエストを受け取り、あなたのビュー関数を呼び出します。Flutterはアプリを実行し、何を描画するかについてあなたのウィジェットに尋ねます。Unityはゲームループを実行し、毎フレームあなたのスクリプトを呼び出します。pytestはあなたのテスト関数を見つけて実行します。異なる分野、1つのアイデア：フレームワークはエンジンを所有し、あなたはそれが保持するために構築されたパーツを供給します。

画像が役に立つなら：ライブラリはあなたが構築している間、あなたの横に座っているツールボックスで、ツールが有用なときはいつでも手を伸ばします。フレームワークは建物のフレームに近く、あなたが到着するとすでに立っています。壁、配線、配管にはその場所があり、あなたの仕事は建物をあなたのものにする部屋に入ります。両方ともあなたの労力を節約します。違いは、構築の形状を誰が決めるかです。

構造には期待が伴い、それは機能です。ほとんどのフレームワークは**設定よりも慣例を**実践しています。フレームワークが期待する場所にファイルを置き、期待する方法でものに名前を付け、すべてがセットアップコードなしでそれ自体をワイヤします。Railsはこの言葉を有名にし、ほとんどの最新フレームワークはそのいくつかのバージョンに従います。見返りは、フレームワークを知っている開発者がそれで構築されたプロジェクトを開き、どこを見ればよいかを知ることができるということです。代償は、慣例は何かが機能する前に学ぶべき1つ以上のものであり、それらと戦うことはほぼ常に従うより苦痛ですということです。

制御の反転はプログラムの読み取りとデバッグの方法を変えます。プレーンスクリプトでは、呼び出しスタックはあなたのコードで始まり、その上のすべてはあなたのものです。フレームワーク内では、スタックはフレームワークの内部の深くで始まり、あなたの関数はフレームワークが呼び出すことを選択した入口として表示されます。フック、ハンドラ、ライフサイクルメソッドです。古いジョークはそれを正確に説明しています：「私たちを呼ばないで、私たちがあなたを呼ぶでしょう。」実際には、フレームワークを学ぶことは、そのAPIサーフェスについてのことより少なく、そのタイミング、あなたのどの関数がそれを呼び出すか、いつ、そしてそれが戻ることを期待するものについてのことが多いです。動作があなたを驚かせたとき、答えはたいていそのタイミングに存在し、フレームワークのライフサイクルドキュメントは開いて保つ価値のあるマップです。

Junoフレームワークとライブラリ ライブラリはツールボックスです。あなたのプログラムが主役で、必要になったときにツールをつかみます。フレームワークはより建物のフレームのようなものです。構造はすでに立ち上がっていて、あなたはそれに部屋を構築します。私の頭にぴったり来た略語は、あなたはライブラリを呼び出しますが、フレームワークがあなたを呼び出すということです。

Junoフレームワークとライブラリ あなたはライブラリを呼び出し、フレームワークがあなたを呼び出します。そしてそのフリップは制御の反転と呼ばれます。フレームワークはそれを慣例と組み合わせます。フレームワークが期待する場所にコードを置き、それがそれ自体をワイヤします。慣例と戦うのではなく従う方が、フレームワークをうまく使用するスキルのほとんどです。

Junoフレームワークとライブラリ 制御の反転は、呼び出しスタックがフレームワークで始まり、あなたのコードはそれが呼び出すフックとして表示されることを意味します。だから学ぶべき実際のことはタイミングです。あなたのどの関数が呼び出され、いつ、フレームワークが何を返すことを期待するか。フレームワークアプリのデバッグはそのライフサイクルを読むことで、それが魔法のように感じるのをやめるとすぐに、より良いです。

フレームワークがもたらすもの、そしてそれが要するもの

フレームワークの場合は具体的です。あなたが数週間かかるであろう問題は既に解決されて到着し、難しい端のケースに最初に当たった人によって解決されます。パスワード処理、フォーム検証、ルーティング、レンダリング。あなたのプロジェクトは、新しいチームメイトが数分で認識できる構造を得ます。それはそのフレームワークで構築されたすべての他のプロジェクトと同じ構造だからです。そしてあなたはエコシステムを継承します。プラグイン、チュートリアル、回答された質問、そしてすでに自分たちの道を知っている人の採用プール。

コストは同じくらい具体的で、同じ直線的な見方を受ける価値があります。フレームワークは、あなたが制御しない大きな依存関係であり、独自のバグ、独自のペース、独自の意見を持っています。最初のページがレンダリングされる前には学習曲線があり、あなたが学ぶもののいくつかはプログラミングについてではなくフレームワークについての知識です。あなたのコードはその形にかがみます。これはあなたが長く滞在するほど去ることを難しくします。そしてフレームワークは動きます。主要なバージョンが到着し、パターンが再考され、追いつくことは、プレーンコードでは持たなかった継続的な作業です。

どちらのリストもそれ自体で勝利しません。バランスは完全にプロジェクトに依存するため、どのフレームワークについても尋ねる質問は「このフレームワークはこのプロジェクトをよりシンプルにするか」です。フレームワークはあなたのプロジェクトをよりシンプルにすることでその場所を獲得します。そうするとき、それを喜んで使用してください。そうでないとき、次の2つの章はそれを早期に認識することについてです。

エコシステム効果は、プラス側の過小評価されたエントリです。成熟したフレームワークでは、あなたの問題が新しい可能性はほぼゼロです。認証、ファイルアップロード、メール送信、デプロイ、各フレームワークはそれぞれをパッケージまたはドキュメント化しました。これは構築の多くの日を組み立てる時間に変換します。マイナス側のミラーリングされたエントリは、この流暢性がフレームワークで単位化されることです。あなたが知っていることのいくつかは「ウェブサーバーがどのように機能するか」ではなく「Djangoはどのようにそれを行うか」です。各便利さの下の一般的なアイデアに目を保ってください。これはこれらのドキュメントが対象としているものです。

2つのコストは本番環境でのみ表示されます。まず、抽象化はリークします。フレームワークの便利なサーフェスは実際の機械を隠し、魔法が誤動作する日に、あなたはあなたが書かなかった追加のレイヤーを通じて機械をデバッグして終わります。あなたのフレームワークが下でどのようなことをするかを理解するために予算を立ててください。なぜなら、最終的にあなたはそれを必要とするでしょう。次に、アップグレードトレッドミルは実際の項目です。大規模なコードベースの主要バージョン移行は数週間を吸収でき、それをスキップすると静かに修正されていないセキュリティの問題に変わります。両方をプレーンコードの代替案と比較すると、移動する部品が少なく、移行するものがありませんが、解決されたすべての問題を再び開いて、あなたの危険で解決します。そのトレードはフレームワークの選択と学習の対象です。

Junoフレームワークがもたらすものとコスト フレームワークはあなたに解決されたプロブレム、認識可能な構造、そしてヘルプの全体的なエコシステムを渡します。その代わりに、あなたは大きな依存関係、学習曲線、そしてそのやり方をするという負担を取ります。両側が実在しているため、あなたが特定のプロジェクトをより単純にするかどうかについての質問を携帯するには、時々答えは幸せなイエスで、そして時々プレーンコードはより穏やかなパスです。

Junoフレームワークがもたらすものとコスト エコシステムはトレードの過小評価された半分です。成熟したフレームワークでは、あなたがほぼ当たらない問題はありません。ただし、各便利さの下の一般的なアイデアに気づき続けてください。そうでなければ、あなたの知識は「この物がどのように機能するか」ではなく「このフレームワークはどのようにそれを行うか」になります。フレームワークはプロジェクトをシンプルにするはずです。それが全体のテストです。

Junoフレームワークがもたらすものとコスト 2つのコストは後で請求します。抽象化はリークするため、ある日あなたはあなたが書かなかったレイヤーを通じてフレームワークの機械をデバッグし、主要なバージョン移行は永遠にスキップできない実際の仕事です。プレーンコードの独自の価格と一緒にそれらを前もって価格を付けてください。フレームワークが仕上げた問題を再度解決します。両方の請求書を支払いました。どちらも楽しくはなく、どちらもドグマの理由ではありません。

ここからどこへ行くか

アイデアが整ったので、次の自然な質問は、そこに実際に何があるかです：フレームワークの種類ではウェブからゲームテストまで主要ファミリーをツアーし、各ファミリーで最も人気のあるオプションを使用します。その後、フレームワークの選択と学習は、フレームワークを選択し、1つを学習し、すべてを必要としないときを知ることについて実用的になります。そして上記のJavaScriptの例が不慣れに感じた場合、JavaScriptトラックは言語そのものをカバーし、それはそれで構築されたフレームワークの前に最初のステップです。