フレームワークを使用しない場合[終了]

今日、ほぼすべての言語に対応するフレームワークを見つけることができ、ほぼすべてのプロジェクトに適合します。最新のフレームワークのほとんどは（一般的に言えば）かなり堅牢であり、1時間ごとのテスト、ピアレビューされたコード、優れた拡張性を備えています。

ただし、コミュニティとしてのプログラマーが選択したフレームワークに依存するようになり、基盤となる動作を理解できなくなったり、新しいプログラマーの場合は基盤となる動作を決して学んだりしないという点で、フレームワークにはマイナス面があると思いますで始まる。「PHPプログラマー」ではなく、「Drupalプログラマー」であるという程度まで専門化するのは簡単です。

誰が気にしますか？フレームワークがあります！「手作業で行う」方法を知る必要はありません！右？

この基本的なスキルの喪失の結果（フレームワークを使用しないプログラマーが「時代遅れ」と見なされる程度まで）は、必要または適切でないフレームワークを使用するのが一般的な慣行になることです。特徴フレームワークの促進が基本言語でできることと混同し羽目になる。開発者はフレームワークを使用して最も基本的なタスクを達成するため、かつては初歩的なプロセスと見なされていたものに、独自の癖、バグ、依存関係を持つ大きなライブラリが含まれるようになりました。かつて20行で達成されていたことが、20,000行のフレームワークを含め、フレームワークを使用するために20行を書くことで達成されました。

逆に、車輪の再発明は望まないでしょう。基本的な一般的な小さなタスクを達成するためのコードを書いている場合、フレームワークXYZが私が望んでいるすべての機能を提供していることを知っていると、時間を無駄にしているように感じるかもしれません。「もっともっと」の部分はまだ心配していますが、多くの人がもうそれを検討しているようにも思えません。

フレームワークを使用するのが適切かどうかを判断するには、適切なメトリックが必要です。しきい値は何だと考えますか、フレームワークをいつ使用するか、または使用しないかをどのように決定しますか。

「フレームワークを使用するのが適切かどうかを判断するには、適切なメトリックが必要です。」

あんまり。テクノロジの適切な使用を判断するための適切なメトリックがあれば、言語、エディター、および方法論の聖戦は見られません。

私が協力したグループはすべて同じことをします-コストと利益を推測し、最も生産的なルートを選択し、それらが正しいことを望みます。それはひどく科学的ではありません-1つの部分の直観、3つの部分の経験、1つの部分のマーケティングへの感受性、1つの部分のunning、そして5つの部分のランク意見。

フレームワークは単なるツールです。使いすぎてもフレームワークのせいではなく、使いすぎた人のせいだと思います。「ハンマーを持っていれば、すべてが釘のように見える」という古い格言は、この考え方がコンピューターよりもずっと前から存在していたことを示しています。

開発者にとっても生物種にとっても、専門性が高すぎると長期的に問題になる可能性があります。長期的な生存のためには、複数の分野でスキルを伸ばすための努力のバランスを慎重にとる必要があります。

あなたの特定の質問に答えるために、私はこれにメトリックがあるとは思わない。問題解決を簡素化するときにフレームワークを使用することを好みます。フレームワークを使用すると、20行ではなく2行のコードで問題を解決できる場合は、明らかにそれを使用します。ただし、20行に対して20行であったとしても、問題のドメインにより近い抽象化が得られ、コードの理解と保守が容易になる場合は、フレームワークを使用することにします。

ある状況ではフレームワークが使いすぎになる可能性があると思います、はい。フレームワークは単なるツールです、はい。フレームワークを使用すると、何かを非常に迅速に実行できます。そのため、優れたプロトタイピングツールです。

線に沿ったどこかで、アプリケーションがある程度の複雑さに達すると、フレームワークに固有の制限がさらなる成長を抑え始めます。秘Theは、そのような転換点にいつ出会ったかを認識し、それから何をするかを決めることです。

私はほとんどの場合、Webアプリケーションを使用する傾向があり、一般的にしようとしても、私の答えはプログラミングの分野には当てはまらないかもしれません。

また、「ライブラリ」と同義の「フレームワーク」を使用します。

フレームワークを実装する前に、いくつかのことを考慮する必要があります。ここにいくつかの一般的な例を示します。

＃1。フレームワークは時間と労力を節約しますか？

この質問に対する答えはほとんど常にあるそう。フレームワークは特定の問題を解決するために構築される傾向があり、それらを非常にうまく解決します。たとえば、EntityFrameworkなどのフレームワークを使用すると、SQLコードを記述する必要がまったくなくなります。プログラミングチームがSQLに堪能でなければ、これは素晴らしいことです。

フレームワークは、a）複雑なコンポーネントにプログラマ向けのインターフェイスを追加するか、b）既知の（または確立された）コンポーネントに抽象化を追加するために構築されます。

後者（または場合によっては前者）は、実際に開発の邪魔になります。これは、特にあなたまたはあなたのプログラミングチームが新しいフレームワークを実装する場合に当てはまります。

これにより、開発プロセスが遅くなり、コストがかかる可能性があります。

＃2アプリケーションの規模

「やりがいのあることはやりすぎの価値がある」と言われていますが、通常はそうではありません。アプリケーションのポイントが"potato"を印刷することである場合、超大規模なフレームワークを実装する正当な理由はおそらくないでしょう。

アプリケーションを開発するとき（Web、デスクトップ、モバイル、または他の考えられるタイプのアプリケーション）-フレームワークのサイズが（おそらく将来の）実装を「小さくする」と感じるなら、これは大きいかもしれませんフレームワークがアプリケーションを肥大化させる可能性があるという警告サイン。ドキュメントの準備ができたときにbodyタグに「ロードされた」クラスを追加するだけで、jQueryを含めた場合の良い逸話になります。ネイティブJavaScriptだけでそれを行うのは少し難しいかもしれませんが、アプリケーションを肥大化しません。

一方、フレームワークが内部で多くの汚い作業を行っている場合（データベースフレームワークなど）、フレームワークを「部分的に」使用している場合でも、実装することが可能です。良い逸話は、ライブラリ全体を利用する必要がないという理由だけで、独自のADO.NETまたはMongoDB-driverを構築しようとしないことです。

フレームワークはオープンソースで提供される場合があります（「やりたい放題」ライセンスが付いています）。これにより、プログラミングチームがフレームワークの一部のみを選択する可能性が新たに広がります。

これは最終的に質問＃1と＃3に結びついています。

＃3インパクト。

フレームワークを実装すると、エンドユーザーに直接影響する場合があります。これは、Webアプリケーションの場合に特に当てはまります。なぜなら、大きなクライアント側のフレームワークがあると、エンドユーザーのエクスペリエンスに悪影響を及ぼす可能性があるからです。速度の遅いマシンを使用しているユーザーは、レンダリングが遅い、javascriptのパフォーマンスの問題、または標準以下のマシンに起因する同様の問題が発生する可能性があります。接続が遅いユーザーは、（少なくとも最初の）読み込み時間が遅くなる可能性があります。

他のタイプのアプリケーションでも、エンドユーザーはアプリケーションの依存関係によって悪影響を受ける可能性があります。フレームワークは、少なくとも常に取り、いくつかのディスクスペースを、そしてあなたがモバイルアプリ（あるいはデスクトップアプリケーション）を開発している場合、これは考慮に入れなければ必要になる場合があります。

サーバー側のフレームワーク（さらにWeb固有）は、エンドユーザーにはほとんど影響しませんが、インフラストラクチャには影響します。一部のフレームワークには依存関係があるため、Webサーバーを再起動する必要があります。サービスのみまたはサーバー全体を再起動する必要があります。

一部のフレームワークは、リソースを非常に多く使用する場合もあります。

もちろん、これはポイント＃1と＃2に結びついています。

それはすべて大きな「考察の輪」であり、フレームワークを実装すべきかどうかを決定するための実際の科学的方法はありません。

コービンマーチはそれを非常によく要約しました。

私が協力したグループはすべて同じことをします-コストと利益を推測し、最も生産的なルートを選択し、それらが正しいことを望みます。それはひどく科学的ではありません-1つの部分の直観、3つの部分の経験、1つの部分のマーケティングへの感受性、1つの部分のunning、そして5つの部分のランク意見。

エリートではないことも重要です。フレームワークは、使用するためのツールです。私は両方の極端な人々を知っています。一方には、自分のために非常に苦労している人がいます。他方には、遅くて肥大化したアプリケーションを構築する人がいます。

すべてのフレームワークにはユースケースがあり、それは正しい目的のためにそれらを実装するだけの問題です。

他の開発者はフレームワークを知っていますか？

すべての開発者がフレームワークXを知っている場合、フレームワークを使用する他のすべての理由が実行可能である場合、それを選択してください！私にとって、開発時間の大部分がフレームワークの複雑さの学習に費やされる場合、特定のフレームワークの学習を強制することは意味がありません。

基本を知らない新しいプログラマーに関するあなたの声明に関して、あなたは私よりもはるかに思いやりがあります！はい、それは残念ですが、私は他の誰かの無能さを心配して時間を費やすつもりですか？うん （コミュニティのこれらの新しいメンバーがすぐにあなたと働いていないという仮定に基づいています。）

次の条件が当てはまる場合（およびその場合のみ）、フレームワークを使用します。

このフレームワークはしばらくサポートされる可能性が高いようです。私は彼らに人生の終わりを告げたことがありますが、それは本当に迷惑です。特に、プロジェクトを始めて9か月のとき、切り替えはもはや選択肢ではありません。フレームワークがすでにサポートされていない場合は、そのフレームワークを使用して何か新しいことを書く前に3回考えてください。どんなによく知っていても。

プロジェクトは実際にフレームワークと一致します。かなり古い例として、MFCが実行されるようにしたことを見ましたか？人々はそれが意味をなさないタイプのアプリでそれを動作させるために奇妙なことをやめませんでした。通常、MFCに勝つために必要なアプリを書くだけで費やすよりも多くの時間を費やします。

プロジェクトチームは、フレームワーク内で作業できます。特定のフレームワークでアプリを記述する方法を理解していない、または理解できない人もいます。その代わり、フレームワークが必要とする方法ではなく、通常の方法で物事を記述します。通常、このコードとフレームワークの不一致は、多くの時間と労力を費やしてしまいます。