フレームワークは抽象化しすぎていますか？[閉まっている]

私は1年弱のプログラミングを行っており、企業/組織向けのシステムアプリケーション、Webアプリ、およびスクリプトの記述経験があります。ただし、Django、Rails、Zendなどのフレームワークを使用することは、私が実際にやったことがありません。

Djangoフレームワークを見ると、フレームワークでどれだけ抽象化されているかに少しイライラしています。私はDRYと最小限のコードの中核的な目標を理解していますが、さまざまなモジュールへの過度の依存とコア機能の重い抽象化の一部は次のように感じます。

1. モジュール/フレームワークの絶えず変化する性質のため、プログラムの日付を非常に速くします。

2. 多数のフレームワークとモジュールが利用可能であり、すべての特異性があるため、コードを理解しにくくします。

3. すべてのドキュメントを読んでいない限り、コードを論理的にしません。つまり、リストの内包表記と条件付きロジックを読んでプログラムの動作を理解することができますが、任意の文字列と辞書を渡す必要がある関数を見ると、すでに第一人者でない限り、物事を理解するのは少し難しくなります指定されたモジュール。そして：

4. フレームワークを切り替えるのが難しく、面倒です。言語の切り替えはすでに課題ですが、その中核となる機能/哲学を十分に理解している場合は管理しやすくなります。フレームワーク間の切り替えは、暗記の問題であるように思われます。これは、いくつかの点で、これらのフレームワークが排除するように設計された非常に非効率性を助長するようです。

MySQLクエリのような単純なものの上に50層の抽象化を実際に配置する必要がありますか？準備されたステートメント/入力テストは処理されますが、普遍的に理解可能なSQLクエリは依然として関数の一部であるPHPのPDOインターフェイスのようなものを使用しないのはなぜですか？

これらの抽象化は本当に便利ですか？機能が肥大化することで無駄になり、フレームワークを使用せずに作成された同様のアプリケーションと比較して、アプリケーションが難しくなりませんか？

フレームワークは確かに扱いにくい場合があります。フレームワークがあまりにも「意見が多い」場合、つまり特定のスタイルのアプリケーションを本当に好む場合、およびすべての部分がこの特定のスタイルをサポートするように調整されている場合、問題が発生しやすくなります。

たとえば、フレームワークがユーザーの認証プロセスを完全に抽象化して、コンポーネントを1つ追加するだけで、どこかにログインテンプレートを追加すれば、ユーザー認証を無料で取得できます。これにより、Cookie、セッションストレージ、パスワードハッシュなどを心配することで、多くの反復作業を節約できました。

問題は、フレームワークの認証コードのデフォルトの動作が必要なものではないことに気付いたときに始まります。たぶんそれは最新の最高のセキュリティ慣行に従っていません。プロセスにカスタムフックが必要な場合がありますが、フレームワークでは提供されていません。設定されているCookieの詳細を変更する必要があるかもしれませんが、フレームワークはこれをカスタマイズする方法を提供していません。

フレームワークによって提供される抽象化により、最初は数日ではなく数分以内に重要な機能をサイトに追加できましたが、最終的にはフレームワークと戦って必要なことを行う必要があります。とにかく機能を最初から作り直さなければなりません。

これは、フレームワークの抽象化が悪いということではありません。これは常に念頭に置いておく必要がある可能性があると言うことです。一部のフレームワークはこれに明示的に適合しており、非常に特定の限られたタイプのアプリのプロトタイプまたは実動フレームワークとして何かを非常に迅速に立ち上げる方法を提供します。他のフレームワークは、使用できるコンポーネントのゆるやかなコレクションに似ていますが、それを使用して後から変更することもできます。

抽象化を使用する場合、少なくとも抽象化されているものを常に大まかに理解する必要があります。Cookieと認証システムを理解していない場合、抽象化から始めるのは得策ではありません。あなたがやろうとしていることを理解しており、退屈な独自のコードを書くのではなく、既にそれを行うコードが必要な場合、抽象化は時間の節約になります。アブストラクトに書かれた抽象化は後であなたをトラブルに巻き込む可能性があるため、両刃の剣です。

また、技術的抽象化と「ビジネスルール」抽象化を区別する必要があります。高レベル言語でのプログラミングはおそらく見逃したくない抽象化（Python、PHP、C＃対C対アセンブラー、低対CSS）ですが、「ビジネスルールの抽象化」はそうしなければ難しい場合がありますニーズを正確に満たします（ワンクリック認証とハンドコーディングCookie）。

それは、技術的な抽象化がめったに「リーク」しないためです。つまり、Pythonでアプリケーションを作成するときにマシンコードをデバッグする必要はほとんどありません。ただし、ビジネスルールの抽象化は同じ技術レベルで機能し、実際には「コードバンドル」にすぎません。おそらく、設定されたCookieまたはある時点で作成されたパスワードハッシュをデバッグする必要があります。これは、多くのサードパーティコードを飛び回ることを意味します。

抽象化とコードの再利用を誤解しているように思えます。

ソフトウェア開発業界全体は、抽象に基づいて構築されています。それらを使用しない、つまり、フレームワーク、ライブラリ、および社内で作成されていない一般的なコードを使用しないことを避けるという理由だけで、ソフトウェアの生産に必要なコストが数十万、おそらくはさらに増加し​​ます。

ジャンボジェットをゼロから作成しないように、他の航空機を構築する際に長年開発したエンジニアリングの知識を使用せずに、ゼロからビジネスソフトウェアを作成することはできません。

そもそもPHPまたはRubyを使用することでそれを実現できますが、すでに膨大な数の抽象化がありますよね？最も明白なもの：

1. オペレーティングシステム、プログラミング言語、およびコンパイラは、アセンブラーとハードウェアを大幅に抽象化し、

2. Webサーバーは、ソケット、フェイルオーバー、HTTPプロトコルなどの抽象化を提供します。

3. SQLは、データが永続的なストレージサポートに保存され、より高速なアクセスのためにメモリに保持される方法を抽象化し、ACID、ミラーリングなどを保証します。

オペレーティングシステム、Webサーバー、データベース、高レベルプログラミング言語のいずれも使用せずに、常にWebアプリを作成しようとする場合があります。あなたはすぐにあなたがすなわち再作成、車輪の再発明年を過ごしたことがわかります、あなたのプログラミング言語、あなたのウェブサーバとあなたのその品質ははるかに私たちが実際に使用する製品の品質からだろうことを考えると、データベースを。

フレームワークはそれと違いはありません。あなたは彼らがすることをすることができます。同じ機能をやり直すのに時間を浪費するだけで、それらのフレームワークはより良い結果を出し、非常に頻繁にコードがあなたのものよりもテストされ文書化されるという違いがあります。

eコマースWebサイトのカートの例を見てください。独自に発明して数週間かけて開発することも、フレームワーク内の多くの人々によって長年開発されたものを使用することもできます。数年の間に、これらの開発者が自分のカートを開発するときに想像もできないようなバグを発見し、パッチを当てたという事実を考慮せずに、彼らのテストが期待されます。

ユーザーケースが多いため、彼らはもっと複雑だと答えることができます。たとえば、彼らはリベートを処理する必要がありますが、ウェブサイトにはリベートがなく、カートにこの機能は必要ありません。まあ、あなたはこの機能を使用することを強制されていません、そしてそれはあなたのウェブアプリのパフォーマンスにペナルティを課すというわけではありません。

既存のカートを使用するのではなく、独自のカートを開発する方が本当に簡単な場合、非常に基本的なシナリオがあります。同様に、アプリが必要とするのが数字のリストを保存することだけである場合、データベースは必要ありません。単純なテキスト入力で十分です。そのような場合、アプリを過剰に設計しないでください。シンプルなシナリオにはシンプルなソリューションが必要です。

別の要因は、コードの可読性です。eコマースWebサイトを作成したと想像してください。その後、プロジェクトを離れ、別の開発者がそれを保守する必要があります。

• フレームワークが提供するカートを使用した場合、同僚は安心します。彼は、信頼性が高く、文書化されたフレームワークに依存する小さなコードを維持する必要があります。さらに良いことには、この開発者はこのフレームワークを操作するために使用されている可能性があり、使い慣れています。そうでない場合、彼はStack Overflowで質問することができます。確かに、誰かが既にフレームワークを使用しています。

• 自分のカートがある場合、同僚はどこかで助けを得ることができずに、おそらく文書化されていないカスタムコードを維持する必要があります。

フレームワークを使用すると、次のコードに依存します。

• 経験豊富な開発者によって書かれ、

• 多くの場合、ペアレビュー済み、

• ユニットテスト済み、

• 広範囲に文書化され、

• 何千人もの開発者が何年も使用し、

• 多くの場合、サポートされているため、バグを報告して実際に修正されたことがわかります。

• 考えられる警告と問題を知っており、Stack Overflowなどのサイトで役立つ多くの開発者に知られています。

• 今すぐ無料で利用できます。

私は同意します-ほとんどのフレームワークは肥大化した独裁者になります。彼らは自由を約束しますが、あなたは奴隷になります。フレームワークをツールのように見てください。最高のツールは邪魔にならないものです。PHPでCodeigniterフレームワークをチェックすることをお勧めします。これは、慣習と自由のエレガントなバランスと優れたコミュニティがあるためです。そして、eコマースカートの例を使用したポスターに-私はあなたに同意できることを望みます。しかし、多くのeコマースソリューションのコードを見て、いくつかを設計したので、あなたの例には敬意を表しません。

うーんLedgerSMBでよくやったことの1つは、フレームワークへのアプローチでした。ただし、この種の抽象化には2つの基本的な問題があります。これらは：

1. 依存関係の爆発

2. 間違った抽象化

最初は、車輪を再発明している代替案よりも実際に優れています。2つ目は、定義が不十分な問題の場合や、多くの場合、意図した用途以外の何かを使用している人が原因である可能性があるため、ラベル付けするのが少し難しいものです。

たとえば、ORMを見てみましょう。ORMの使用を避けるのは、せいぜい漏れやすい抽象化レイヤーであるため、dbが最終的にアプリケーションのオブジェクトモデルに合わせて設計されることが多いためです。これは必ずしもそうではありません。ORMを使用しながら、優れたDB設計と優れたアプリを保持することができた開発者に会ったことがありますが、更新可能なビューの背後にあるdbのリレーショナルAPIをカプセル化するなど、ormの誇大広告は必要ではないという多くのことに頼っています。

もちろん、大きな問題は、特に不透明でもコードが高度に自動化されるほど、何が問題なのかを見るのが難しくなることです。これは、@ jhewlettが上記で作成したORMに関するポイントです（/software//a/190807/63722を参照）。

航空機を操縦するためのフレームワークとしての高度なアビオニクスは、優れた類似点です。これらは信頼性のために高度に設計されており、飛行の安全性を高める要因です。ただし、IEEE Spectrumの多くの記事が指摘しているように、これは自動化の観点から許容できると考えられるものの範囲外のエラーからの回復可能性を犠牲にします。デバッグについても同じことが言えます。プログラムでSQLコードをデバッグすることは1つのことです。プログラムが使用するSQLコードを作成するプログラムの一部をデバッグすることは、まったく異なります。

LedgerSMBフレームワークをゼロから作成したのは、開始した時点で、望んでいたことを実現する本当に良いフレームワークがなかったからです。それは実際、私がかなり満足していることの1つであり、プロジェクトの新しい開発者によると、アプリケーションのカスタマイズが非常に簡単になります。（実際には、SQLコードの生成を最小限に抑え、代わりに手書きのユーザー定義関数に焦点を当てています。つまり、SQLの記述部分は非常に薄い接着剤です。はい、それはいくつかの場所で多くの抽象化を提供します、何人かのプログラマーが慣れているよりも（特に「そのストアドプロシージャの引数へのオブジェクトプロパティのマッピング」は私たちを時々押し戻します）。ただし、何が問題なのかを簡単に判断できるように、すべてをシンプルで一貫したものにするよう努めています。これはかなりうまくいきます。

最終的には「多すぎる」は少し主観的ですが、客観的なレベルではあなたが何をしているかにも依存します。フレームワークが行うように設計されたものを正確に実行している場合、適切に設計されたフレームワークは完璧な量の抽象化を提供します。少し適合性の低い何かをしている場合、抽象化は多すぎて漏れやすくなります。

はい、便利です。彼らはあなたが解決する必要がある問題を解決するために仕事をしている他の多くの経験豊富な開発者の利益を提供し、それをテストし、多くのバグを修正し、心配する必要のない厄介な問題に対する解決策を提供するという追加の利点を提供しますフレームワークを使用して自分自身。

彼らは肥大化することができますか？はい。これはすべて、必要なものと、フレームワークがテーブルにもたらすものに依存します。単純なWebアプリを使用している場合、Railsは多すぎるかもしれません。Sinatraのような単純なソリューションをソリューションとして検討する必要があります。

すべてのフレームワークには間違いなく学習曲線があり、より多くの作業を節約できるため、より急勾配になります。ただし、フレームワークを学習すれば、時間を節約でき、アプリケーションを最初から書き直すのではなく、次のプロジェクトでその知識をすべて活用できます。

ただし、古いプロジェクトからコードをコピーするだけで、それを新しいプロジェクトの出発点として使用できます。異なる点を変更し、オブジェクト/関数の一部をより一般的なものにし、そのトリッキーなコードを解決するためのより良い方法を考えます！おめでとうございます、あなたはフレームワークを作成しました。これをさらに数千回実行すると、Django、Rails、またはZendのようなものがあります。

フレームワークは通常、生産性を向上させますが（おそらくわずかな学習曲線の後）、多くの場合トレードオフが伴います。たとえば、場合によっては、パフォーマンスが低下する代わりにプログラマの生産性が向上します。

オブジェクトリレーショナルマッパー（ORM）を検討してください。面倒なマッピングコードの多くを処理してくれるという点で優れています。彼らはあなたのためにあなたのオブジェクトを作成するかもしれません。ただし、SQLを抽象化する場合、パフォーマンスについて推論し、ボトルネックを最適化することははるかに困難です。

大量のデータや複雑なクエリを持たないアプリケーションを構築している場合、パフォーマンスは問題にならないかもしれません。実際、プログラマーの時間は多くのプロジェクトのボトルネックであり、フレームワーク、ライブラリー、および高水準言語はそれを軽減するのに役立ちます。

「あなたはライブラリを使用しますが、フレームワークはあなたを使用します」ことに同意します。それは非常にきちんとした方法です。コードの再利用を開始するとすぐにフレームワークの構築を開始することに同意しません。通常、コードを再度使用するために簡単なコピーと貼り付けだけを行う必要があります。構築しているライブラリ。サイトやアプリにコードをどのように組み込むかについて気にする必要はありません。

私にとって重要な点は、投資を必要とするよりも多くのリソースを活用する必要があるということです。または、別の角度から、フレームワークのニーズが利用可能な報酬よりも大きくなるとすぐに、すべての利点がなくなると言います。だから「はい！お願いします！そしてありがとうございました！' 私自身のhtml / CSS / PHPおよびSQL内で必要に応じてまっすぐ落ちて機能するアセットを作成するすべての人に。

私が理解できないと思うことの1つは、フレームワークがメンテナンスを容易にするということです。インターワーキングパーツの複雑なメッシュが意図したとおりに機能しない場合は、問題のフレームワークについて知っておくべきことをすべて知っておくとよいでしょう。または、新しい構文を大量に入力する準備をしてください。

これは、フレームワークのハリウッド原則であると言う人もいます。対照的に、ライブラリを使用するときは常に、コードはライブラリを呼び出しますが、その逆ではありません。

ご覧のとおり、重要なポイントは、誰が制御しているのか、つまり制御の流れを制御しているのかです。誰がどのステートメントをどのステートメントの後に実行するかを決定しますか？

賛否両論の議論があり、そのような終わりのない議論を見るときはいつでも、これは客観的に決定可能な質問ではなく、好みの問題でなければならないと思う傾向があります。そうでなければ、それはすでに決定されていたでしょう。

私の見解では、フレームワークまたはライブラリを使用することを好むかどうかは、あなたがどのような開発者であるかを示しており、両方のアプローチのどちらが優れていて最終的に勝つかはわかりません。

フレームワークを好む場合は、セキュリティと自由を交換することを好みます。おそらくより実用的であり、他の人が自分の仕事を適切に行うことを信頼する傾向があります。ライブラリを好む場合は、セキュリティを自由に交換することを好むでしょう。あなたはおそらく理想主義者であり、他者のアイデアや主張に疑問を投げかけるでしょう。

前者や後者のようにした方が良いと判断するのは賢明だとは思いません。

あなたの質問に答える：フレームワークは抽象化しすぎていますか？それはあなたが誰であるか、具体的には第一原則からどのくらい離れているかによって異なります。

...

さらに具体的には、Djangoのようなフレームワークが気に入らない場合は、Flaskのような「マイクロフレームワーク」を検索してください:)