フレームワークを使用しない場合
今日では、ほぼすべての言語に対応し、ほぼすべてのプロジェクトに対応するためのフレームワークを見つけることができます。最近のほとんどのフレームワークはかなり堅牢（一般的に言えば）で、1時間ごとのテスト、ピアレビュー済みのコード、優れた拡張性があります。
ただし、コミュニティとしてのプログラマーは、選択したフレームワークに依存しすぎて基礎となる仕組みを理解できなくなったり、新しいプログラマーの場合は基礎となる仕組みを学習したりしないため、フレームワークには欠点があると思いますで始まる。あなたが「PHPプログラマー」（たとえば）ではなく、「Drupalプログラマー」ではないことを専門にして、他のことを排除するのは簡単です。
誰も気にしないでしょ？私たちはフレームワークを持っています！ 「手動で行う」方法を知っている必要はありません。正しい？
この基本的なスキルの喪失の結果（フレームワークをしない使用するプログラマーが「時代遅れ」と見なされる場合もあります）、必要のない場所でフレームワークを使用することが一般的になります。または適切。 featuresフレームワークは、基本言語の機能と混同されてしまうのを容易にします。開発者はフレームワークを使用して最も基本的なタスクを実行し始めます。そのため、かつては基本的なプロセスと考えられていたものに、独自の癖、バグ、依存関係を持つ大規模なライブラリが含まれるようになります。かつて20行で行われていたことは、現在は20,000行のフレームワークを組み込み、そのフレームワークを使用するために20行を書き込むことで実現されています。
逆に、ホイールを再発明したくありません。基本的な一般的な小さなタスクを実行するコードを記述している場合、フレームワークXYZが私が求めているすべての機能を提供していることを知っていると、時間を無駄に費やしているように感じるかもしれません。 「もっといっぱい」の部分はまだ心配ですが、それを考える人すらいないようです。
フレームワークを使用することが適切である場合を判断するための適切なメトリックが必要です。 youフレームワークをいつ使用するか、または使用しないかをどのように決定しますか。
「フレームワークをいつ使用するのが適切かを判断するには、適切な測定基準が必要です。」
あんまり。テクノロジの適切な使用を判断するための優れた指標がある場合、言語、編集者、および方法論の聖なる戦争は見られません。
私がこれまで取り組んできたグループはすべて同じことをします-コストと利益を推測し、最も生産的なルートを選択して、それらが正しいことを願っています。それはひどく科学的ではありません-1つの部分の直感、3つの部分の経験、1つの部分のマーケティングへの感受性、1つの部分の狡猾さ、および5つの部分のランクの意見。
フレームワークは単なるツールです。フレームワークの使いすぎはフレームワークのせいではなく、使いすぎた人のせいだと思います。 「ハンマーを持っていると、すべてが釘のように見える」という古いことわざは、この考え方がコンピュータでさえずっと前に存在していたことを示しています。
専門化しすぎると、長期的には問題が発生する可能性があります-開発者にとっても、生物種にとっても。長期間生存するためには、複数の領域で自分のスキルを伸ばす努力のバランスを慎重にとる必要があります。
あなたの特定の質問に答えるために、私はこれのための測定基準があるとは思いません。フレームワークを使用すると、問題解決が簡単になります。フレームワークを使用すると、20行ではなく2行のコードで問題を解決できる場合は、明らかにそれを使用します。しかし、20行に対して20行であったとしても、問題の領域に近い、コードの理解と保守を容易にする、より良い抽象化を提供するフレームワークを使用することを決定するかもしれません。
フレームワークは、一部の状況では使いすぎていると思います。フレームワークは単なるツールです。フレームワークを使用すると、非常に迅速に何かを実行できるため、優れたプロトタイピングツールです。
どこかで、アプリケーションがある程度の複雑さに達すると、フレームワークに固有の制限がさらなる成長を抑制し始めるように思えます。秘訣は、そのような転換点にいつ遭遇したかを認識し、次にそれについて何をするかを決定することです。
私はWebアプリケーションを最もよく使用する傾向があり、一般的になろうとしているにもかかわらず、私の答えはあなたのプログラミング領域には当てはまらないかもしれません。
また、「ライブラリ」と同義の「フレームワーク」を使用します。
フレームワークを実装する前に、いくつかのことを考慮する必要があります。以下にいくつかの一般的な例を示します。
＃1。フレームワークは時間と労力を節約しますか？
この質問への答えはほとんど常にyesです。フレームワークは、特定の問題を解決し、それらを非常にうまく解決するように構築される傾向があります。たとえば、EntityFrameworkなどのフレームワークを使用すると、SQLコードの記述から全体を節約できます。プログラミングチームがSQLに堪能でない場合、これは素晴らしいことです。
フレームワークは、a）プログラマーフレンドリーなインターフェイスを他の複雑なコンポーネントに追加するか、b）既知の（または確立された）コンポーネントに抽象化を追加します。
後者（場合によっては前者でさえ）は実際に開発の邪魔になることができます。これは特にあなたやあなたのプログラミングチームがこれまで働いたことのない新しいフレームワークを実装しようとしているときに当てはまります。
これにより、開発プロセスが遅くなり、コストが高くなる可能性があります。
＃2アプリケーションの規模
「やりがいのあることはやり過ぎる価値がある」と言われていますが、通常はそうではありません。アプリケーションの目的が印刷 "potato"である場合、超大型フレームワークを実装する正当な理由はおそらくありません。
アプリケーション（Web、デスクトップ、モバイル、その他の考えられる種類のアプリケーション）を開発しているとき—フレームワークのサイズが（おそらく将来の）アプリケーションの実装を「小さくする」と感じた場合、これは大きな問題になる可能性があります。フレームワークがアプリケーションを肥大化させる可能性があることを示す警告サイン。良い逸話は、jQueryを含めた場合、ドキュメントの準備ができたときにbodyタグに "loaded"クラスを追加することです。ネイティブJavaScriptだけでそれを行うのは少し難しいかもしれませんが、アプリケーションを膨らませることはありません。
一方、フレームワークがたくさんの汚れた作業を実行する場合内部（つまり、データベースフレームワーク）では、フレームワークを「部分的に」使用しているだけでも、それを実装することは現実的かもしれません。ライブラリ全体を利用する必要がないからといって、しない独自のADO.NETまたはMongoDB-driverを構築しようとするのが良い逸話でしょう。
時々、フレームワークはオープンソースで提供されます（「do-whatever-you-want」ライセンスが付属しています）。これにより、プログラミングチームがフレームワークの一部のみを選択するという新しい可能性が開かれます。
これは最終的に質問1と3に結びつきます。
＃3インパクト。
フレームワークを実装すると、エンドユーザーに直接影響を与える場合があります。これは特にWebアプリケーションに当てはまります。クライアント側の大きなフレームワークがあると、エンドユーザーのエクスペリエンスに悪影響を与える可能性があるためです。遅いマシンを使用しているユーザーは、レンダリングが遅い、JavaScriptのパフォーマンスの問題、または同等以下のマシンが原因の同様の問題が発生する可能性があります。接続速度が遅いユーザーは、読み込み時間が遅くなります（少なくとも初期）。
他のタイプのアプリケーションであっても、エンドユーザーはアプリケーションの依存関係によって悪影響を受ける可能性があります。フレームワークは少なくとも常にsomeのディスク領域を占有します。モバイルアプリ（またはデスクトップアプリでさえ）を開発している場合、これを実行する必要があるかもしれません考慮に入れます。
サーバーサイドフレームワーク（さらにWeb固有）はエンドユーザーに影響を与えることはほとんどありませんが、インフラストラクチャに影響します。一部のフレームワークには依存関係自体があり、サービスまたはサーバー全体を再起動する必要がある場合があります。
一部のフレームワークは、veryリソースが多い場合もあります。
もちろん、これはポイント1と2に結びついています。
それはすべて大きな「考慮事項の輪」であり、フレームワークを実装する必要があるかどうかを決定する実際の科学的方法はありません。
コービン・マーチはそれを非常にうまくまとめました：
私がこれまで取り組んできたグループはすべて同じことをします-コストと利益を推測し、最も生産的なルートを選択し、それらが正しいことを願っています。それはひどく科学的ではありません-1つの部分の直感、3つの部分の経験、1つの部分のマーケティングへの感受性、1つの部分の狡猾さ、および5つの部分のランク意見。
エリート主義者でないことも重要です。フレームワークは、使用するためのツールです。私は両極端の人々を知っています。一方では、自分自身のために人生を非常に苦労させている男がいます。他方では、遅い、肥大化したアプリケーションを構築している男があります。
すべてのフレームワークにはユースケースがあり、適切な目的のためにそれらを実装するだけの問題です。
他の開発者はフレームワークを知っていますか？
すべての開発者がフレームワークXを知っている場合、フレームワークを使用する他のすべての理由が現実的であるとすれば、それを採用してください！私にとって、開発期間の大部分がフレームワークの複雑さの学習に費やされる場合、特定のフレームワークの学習を強制することは意味がありません。
基本を知らない新しいプログラマーに関するあなたの声明に関して、あなたは私よりもずっと思いやりがあります！はい、それは残念ですが、他の誰かの不適当さを心配して時間を費やすつもりですか？うん。 （これらのコミュニティの新しいメンバーはあなたとすぐには協力していないという前提に基づいています。）
以下の条件が当てはまる場合（および場合にのみ）フレームワークを使用します。
フレームワークはしばらくの間サポートされるようです。以前私は彼らに私に寿命を迎えさせました、そしてそれは本当に迷惑です。特に、プロジェクトに9か月を費やしている場合、切り替えは実際にはもうオプションではありません。また、フレームワークがすでにサポートされていない場合は、そのフレームワークを使用して何か新しいものを書く前に3回考えてください。どれだけ知っていても。
プロジェクトは実際にフレームワークと一致しています。かなり古い例として、MFCが実行するように作られたものを見たことはありますか？人々は、それが意味をなさない種類のアプリでそれを機能させるために奇妙なことを終わらせませんでした。通常、MFCに打ち勝つために費やした時間は、必要なアプリをすぐに作成するよりも多く費やします。
プロジェクトチームは、フレームワーク内で作業することができます。一部の人々は、特定のフレームワークでのアプリの記述方法を理解するために時間をかけないか、または理解することができません。代わりに、フレームワークが必要とする方法ではなく、通常どおりに記述します。このコードとフレームワークのミスマッチは、通常、全員に多大な時間と労力を費やします。