フレームワークの選択と学習

docs.scrimba.com

前の2つの章では、フレームワークとは何かと何が存在するかについて説明しました。このセクションは実践的な部分です：フレームワークを使うべきか、どれを選ぶか、そしてそれを学ぶ方法です。順序が重要です。なぜなら、最初の質問が最も見落とされやすいからです。

そもそもフレームワークを使うべきですか？

2つのプロジェクトを想像してみてください。最初のプロジェクトは、アカウント、フォーム、共有データに反応するスクリーンを備えたアプリです。手作業でそれを実装することは、フレームワークが既に完成させた配管設備を正確に再構築することを意味し、バニラ版は散らばった、テストされていない独自の配管設備になり、誰も引き継ぎたくはありません。ここでDjangoやReactに手を伸ばすことは、別の方法よりも動く部分が少なくなることを選ぶことです。

2番目のプロジェクトは、ランディングページ、コンテンツサイト、小さなスクリプト、どこかに送信するフォームです。プレーンなHTML、CSS、そして少しのJavaScriptで、ビルドステップなし、依存関係の更新なし、来年移行するものはありません。そのようなページを完全なフレームワークでラップすることは、ツーリングだけが恩恵を受ける機械装置を追加します。経験豊富な開発者の多くが目的でバニラを納品し、それは初心者の妥協ではなく、プロフェッショナルな答えです。

エンジニアリングは両方のケースをカバーする率直な古いルールを持っています：KISS、「Keep It Simple, Stupid」。侮辱は設計者ではなく設計そのものに向けられており、最良のソリューションは仕事をこなしながら最も少ない機械装置を持つものであるという考えです。上記の両方のプロジェクトがそれに従い、反対の答えに到達しています。

これにより、テストは1つの質問になります。各プロジェクトのために新しく尋ねられます：維持する機械装置が最も少なくなるオプションを選んでください。配管が製品を圧倒するとき、それはフレームワークです。製品がほぼすべてであるとき、それはバニラです。

いくつかのシグナルは呼び出しを具体的にします。フレームワークに傾いている：多くのスクリーンが共有ライブデータを持つ、ユーザーアカウントとアクセス権限、検証して保存するフォーム、複数の人が数年間同じコードベースで作業しています。バニラに傾いている：ほとんどがコンテンツ、相互作用は少ない、数ヶ月単位の寿命、1人または2人の保守者、または読み込み速度が全機能であるページ。プロジェクトサイズは時間とともに両方向で答えを変える可能性があるため、有用な習慣はプロジェクトが形を変えるたびに質問を改めて尋ねることです。

この決定は2つの認識可能な方法で失敗し、両方とも質問をスキップすることから来ています。最初の失敗はフレームワーク形のランディングページです：ビルドパイプライン、依存関係ツリー、および4画面のコンテンツに付属する最終的なマイグレーション。ツーリングに費やされたすべての時間は、製品が必要としなかった時間です。2番目は偶然のフレームワークです：独自のルーター、独自の状態ストア、独自のコンポーネントシステムを育てるバニラコードベース。それぞれ一度書かれ、テストされ、1人の人に理解されています。その2番目のプロジェクトは、フレームワークの利点なしにフレームワークのコストを支払います。両方の失敗は内側から信念に見えます；両方のケースの修正は、プロジェクトが何になったかに基づいて再決定する同じ地味な動きです。

Junoフレームワークは必要ですか？ プロジェクトごとに1つの質問を尋ねてください：どのオプションが構築と保守する必要が少なくなりますか？アカウントと共有データを備えたインタラクティブなアプリの場合、フレームワークは通常勝ちます。コンテンツページまたは小さなスクリプトの場合、プレーンなコードは通常勝ちます。両方の答えは尊重に値し、プレーンなコードを選択することは決してダウングレードではありません！

Junoフレームワークは必要ですか？ 共有ライブ状態、アカウント、フォーム、長い複数人の人生はフレームワークを指し示します；コンテンツが豊富で、短寿命、または速度に関する重大なページはバニラを指し示します。プロジェクトが形を変えるたびに元の呼び出しを守る代わりに改めて尋ね、毎回プロジェクトごとにそれを作ります。

Junoフレームワークは必要ですか？ 2つの古典的な失敗に注意してください：何もしないためのツーリングコストを支払うフレームワーク形のランディングページ、そして静かに独自の保守されていないフレームワークを育てたバニラアプリ。両方とも選択が決定されたものとして扱うことから来ます。プロジェクトの変曲点のたびに再決定し、それは1回以上両方の溝から私を救っています。

どのように選ぶか

答えが「はい」のとき、地味な基準で選択してください。ベンチマークと機能の比較は、最も有用でない入力です。なぜなら、ファミリー内では人気のあるオプションはすべて十分に高速であり、十分に有能だからです。実際にあなたの毎日の生活を形作るもの：

エコシステムとコミュニティ：成熟したドキュメント、回答された質問、そしてあなたが直面するであろう問題のパッケージ。チームとあなたが参加しているコードベース：最良のフレームワークは通常、あなたのプロジェクトが既に使用しているもの、そして一貫性がチーム内の新規性を打ちます。職業市場、仕事のために学ぶなら：純粋な使用数は重要です。これは、Reactが多くの人々の合理的な最初の選択である大きな理由の一部です。そして、あなたが知っている言語：Pythonデベロッパーは品質とは何の関係もない理由でRailsよりもDjangoをより速く習得します。

バニラオプションをリストの最後に保持してください。比較表が満杯になり、候補者の誰も「none of the above」をシンプルさのテストで打ち負かさない場合、それは何かあなたに語っている答えです。

候補を詳しく見るために、1週間の意見を読むことより1時間の直接的な評価が勝ります：公式のチュートリアルをざっと読んでドキュメントが説明しているかジェスチャーしているかを判断します；リリース履歴をチェックして一定の、気ぜわしくないペースを確認します；「バージョンXからYへの移行」を検索して、これらのガイドが午後のように読むか季節のように読むかを見ます；そしてあなたが尋ねるであろう質問が既に良い答えを持っているかどうかを見ます。フレームワークは長い関係であり、これらは互換性チェックです。

2つの上級の習慣がこれを丸めます。最初に確立されたものに賭ける：数年間広く使用されている技術は既知の失敗モード、採用プール、そして答えを持ち、「証明された少し流行遅れの」は「新しく興奮した」よりもはるかに頻繁に生き残ります。チャーン（変動）は複合的なコストであり、10年間生き残ったフレームワークは既にそれを支払っています。次に、コンポーネントレベルで構築対採用を実オプションとして保持します：時々正しいフレームワークの量はルーティングライブラリであり、他は何もない、1つの困難な問題のために採用されている間、残りはプレーンなままです。フレームワークの採用は全か無かではなく、実際の困難な部分を解決する最小の依存関係は尊重される建築です。

Juno1つを選ぶ 実践的な基準で選択してください：チームが既に使用しているもの、ドキュメントとコミュニティがどの程度優れているか、職業市場が何を望んでいるか、そしてあなたが既に知っている言語。ファミリー内では、すべての人気のあるオプションが良いため、ステークスは感じるほど高くはありません。あなたのスキルはどちらの方法でも転送されます。

Juno1つを選ぶ 候補に1つの焦点を絞った時間を与えます：チュートリアルを読み、リリースのリズムをチェックし、バージョン移行ガイドを読みます。なぜなら、それはあなたが署名している未来だからです。コミュニティ、チームフィット、そして採用はベンチマークを毎回打ちます。そして「フレームワークなし」をショートリストに保持し、目的で最後まで。

Juno1つを選ぶ 確立されたものに賭けてください：10年間生き残ることは、フレームワークが投稿できる最も有用なベンチマークです。そして採用がバイナリではないことを忘れないでください；時々1つの小さなライブラリ1つの困難な問題のための正しいフレームワークの量です。目標は出荷され、出荷可能なままである製品です。

どのフレームワークでも学ぶ方法

最初に言語を学んでください。フレームワークはどこでもその言語を想定しています：Reactコードはジャバスクリプト壁です，Djangoアプリの混乱した行はどれもPythonの下です。フレームワークをスキップする学習者は一度に2つの謎をデバッグするはめになります，フレームワークの動作と言語の構文、どれがどれであるかを判断する方法はありません。Reactがあなたの目標ならば、JavaScriptトラックが実際の最初のステップです；Djangoまたはpytestの場合、Pythonトラックは同じ役割を果たします。言語第一は単一の最大の近道です，なぜなら、それはどこでも転送される部分だからです。

次に、小さくて実際なものを構築してください。公式チュートリアルに依存しながら構築した、あなたが実際に欲しい1つの小さなプロジェクトは、見たり読んだりすることの任意の量より多く教えます。なぜなら、フレームワークの形は独自の手の下でのみ意味をなすからです。最初のプロジェクトを意図的に控えめに保ってください：その仕事全体はフレームワークの考え方を紹介することであり、マスターピースは後で来ることができます。

そしてあなたが進むにつれて、フレームワークがあなたのために何をしているのかを尋ね続けてください。すべての便利な機能は実際のもののために立っています：ルートはURLの解析のために立っている，コンポーネントはDOM更新のために，モデルはSQLのために。あなたはこれらの層を事前にマスターする必要はありませんが、それらが存在することを知ること，そしておおよそフレームワークが何をするのかは、フレームワークを使用することをフレームワークに盲目的に依存することから分離するものです。

この段階での一般的な罠はチュートリアルループです：ガイドなしプロジェクトを始めることなく、コース後のコースを完了させること。なぜなら、チュートリアルは生産的に感じ、空白のファイルは危険に感じるからです。意図的にそれを打破します。1つの公式チュートリアルの後、小さな実際のプロジェクトを開始し、その問題があなたが何を探すかを駆動させます；ライブの問題の手でドキュメントを読むことは、ドキュメントが宿題として読まれる方法では決して付き合いません。あなた自身のプロジェクトで立ち往生して脱出させることは、訓練される実際のスキルです。

2つの習慣は框架の知識を耐久性のあるものにします。脱出ハッチを早期に学ぶ：すべてのフレームワークは、その抽象化の下に落とす方法が認可されています（ORMの過去の生のSQL、レンダラーの過去のDOM直接アクセス），そしてそれらがどこにあるかを知ることは、あなたがめったに使用しなくても機械の境界を教えてくれます。そしてHTTP、DOM、SQL、言語実行時のフレームワークの下の基盤に定期的に投資してください。フレームワークは現在、プラットフォームがどのように保持されているかです；プラットフォームは持続するものです。プラットフォームを知っていた開発者は過去20年間のすべてのフレームワークの遷移を無傷で横断しました，それはコピーする価値のある実績です。

Juno1つを学ぶ 常にフレームワークの前に言語を学んでください：Reactの前にJavaScript、Djangoの前にPython。次に、公式チュートリアルを脇に開いて1つの小さな実際のプロジェクトを構築します。小さく完成した方が大きく放棄されたより優れています，そしてあなたが言語について学ぶすべてがその価値を永遠に保持しています！

Juno1つを学ぶ チュートリアルループから意図的に逃げてください：1つの公式チュートリアル、その後、小さなガイドなしプロジェクト，その問題が決定するあなたが次に何を読むか。ライブの問題の手で研究されたドキュメントは実際に付き合います。あなた自身の仕事で立ち往生して脱出させることは、あなたが本当に訓練しているスキルです。

Juno1つを学ぶ 脱出ハッチを早期に見つけてください；それらは機械の真の端をマークします。そしてフレームワークが回転し、プラットフォームが滞在する理由である、HTTP、DOM、SQL、プラットフォームの知識を給付し続けてください。プラットフォーム人は毎回のフレームワーク遷移を生き残ります；私はいくつか見てきましたし、パターンはまだ逃されていません。

ここがあなたをどこに残すか

それは全体の入門書です：テストとしての単純さ、ピックのための地味な基準、学習のためのフレームワーク前の言語。特定のフレームワークが次に表示されたとき、これらのドキュメントまたは野生で、フレームワークの種類はそれを配置するマップであり、フレームワークとはは下の定義です。