豊富なフレームワークがプログラマを馬鹿にしていますか？[閉まっている]

最近利用可能なすべてのフレームワーク、ORM、依存性注入（DI）、制御の反転（IoC）などにより、多くのプログラマーが困難な問題を解決するために必要な問題解決スキルを失っている、または持っていないことがわかります。多くの場合、予期しない動作がアプリケーションに忍び込み、開発者が問題を実際に掘り下げて見つけることができませんでした。ボンネットの下で何が起こっているかについての深い理解が失われているように思えます。

誤解しないでください、これらのフレームワークが良くないことや業界を前進させていないことを示唆していません。意図しない結果として、開発者が深い理解に必要な知識とスキルを得ていないかどうかを尋ねるだけですシステム。

同意した。私は現在、フレームワークに邪魔されてビジネスを理解することをほとんど不可能にするソフトウェアパッケージに取り組んでいます。フレームワークがMVCを単に解決するのではなく、ビジネス上の問題を実際に解決することからあなたを取り除いたら、それは行き過ぎです。あなたが述べているように、IMOの多くのプログラマーはORMとMVCを解決するためにアーキテクト/プログラムを試みますが、そもそもソフトウェアが問題を解決するのに実際に役立つかどうかを尋ねることはほとんどありません。

ええ、JSPページで生のSQLを見るのは「ノー」だと知っていますが、フィールドコンサルタントの場合、これは特定のソリューションにどこに当てはまりますか？いいえ、それはフレームワークが正しくないという意味ではありません。すべての顧客がページにマイナーデータポイントが投影されるようにするために毎回$ 20,000座っているわけではありません。

これは、多くの分野および多くの形式で定期的に現れる議論です。

この引数の一般的な形式は次のとおりです。

[x：tool / technology]を持っていると、[y：xの影響を受ける機能]が悪化しますか？

例えば：

• CADソフトウェアは、より悪いエンジニアに役立ちますか？
• 高校の計算機は生徒の数学を悪化させますか？
• ソーシャルソフトウェアは、人々の対面ソーシャルスキルを阻害しますか？
• 会計ソフトウェアはより悪い会計士を生み出しますか？

記憶から、ユビキタスな答えはほとんど常にあります：そうではありません。常に上手い人と下手な人がいるでしょうが、今では彼らはスキルの異なる面でただ下手です。

どんな仕事であっても、基本的なことをより深く理解することは、あなたが何をしていようと、助けになるでしょう。知識は常に役立ちます。

抽象化はコンピュータープログラミングの重要な概念であり、フレームワークはプログラマーがこれを達成するのに役立ちます。これは良いことです。私たちの多くがアセンブリ言語で複雑なシステムを開発したいとは思わないでしょう！問題は、プログラマが抽象化レイヤーが何をマスクしているかについてほとんど知らないときに起こると思います。言い換えれば、あなたがそれと直接対話したりインターフェースしたりしていなくても、内部で何が起こっているのかをある程度知る必要があります。

私は、90年代半ばにCとCGIを使用して最初の動的なWebサイトのいくつかを開発したことを覚えています（当時、Webサイトの大半はまだ静的なHTMLでした）。成熟したサーバー側のスクリプト言語（PHPやASPなど）もライブラリもほとんどなかったため、すべてのページでHTTP応答ストリーム全体をサーバーに書き込む必要がありました。GETおよびPOSTパラメーターを解析するには、独自のライブラリを作成する必要がありました。それは退屈で、遅く、勤勉で非常にエラーが発生しやすいものでした。ちょっと見逃さないで！

ただし、ASP.NET Webフォームのようなフレームワークは、Webのステートレスな性質全体を抽象化し、多くの新しいWeb開発者が実際に内部で何が起こっているのかについての手掛かりがほとんどない点まで感じます。これは、開発者がHTTPレベルで何が行われているかを理解せずに「ドラッグアンドドロップ」の方法論を使用してコンポーネントを一緒に配管しているため、パフォーマンスが不十分な非効率的なコードにつながります。

したがって、高レベルのソフトウェアを開発するにはフレームワークが不可欠であると考えていますが、抽象化されているものをある程度理解している開発者を免れません。はい、フレームワークはあなたを愚かにさせることができますが、それはあなたがそれらを理解し損ねた場合のみです。

オートマチックトランスミッションや雨に敏感なフロントガラスワイパーは、ドライバーを悪化させますか？

フレームワークなしのコーディングは、必ずしも基礎となるシステムのより良い理解を意味するとは思わない。これは、候補者が首尾一貫した方法を組み合わせられるようにするために、面接で単純なコーディングの質問をしなければならない雇用主によって証明されています。

最終的に学ぶのは開発者次第です。良いものはそうですが、悪いものはそうではありません。

また、同様の流れで、実際にその機能と長所/短所を分析せずにフレームワークが存在するという理由だけでフレームワークを選択することも、開発プラクティスが不十分であることを示しています。

問題は、新しいプログラマーがより高いレベルの抽象化から始めているため、「裏側」にあるものの断片にさらされないことだと思います。そのため、彼らは過去数年で最初に学んだことになる、本当に基本的なコーディングの基礎を学んでいません。

明らかに新しいプログラマーが何かデータを保存するなどの質問をしているときに、ここで毎回頭を振って、誰もがすぐにORMツールを使用するように言います。 いや、いや、いや、いや、いや...彼らはまず自分でそれをする方法を学ぶ必要があります。

おそらく、「ダム」の分布は実際には変更されておらず、代わりに、開発者が自分自身を撃つためのより大きく複雑な方法を単に配布しているだけでしょうか？

プログラマを馬鹿にするのはフレームワークではありません。愚かなプログラマーは、フレームワークを使用するかどうかにかかわらず、愚かです。

確かに、ツールまたはフレームワークが合理化に役立つ低レベルの作業を理解することで、ツールとフレームワークの優れたユーザーになることが確かです。また、問題をより簡単にデバッグし、ツールの機能の不可避なギャップを回避できます。

たとえば、私は大学でコンパイラデザインのクラスを受講しました。そこでは、lexやyaccなどのパーサージェネレーターの使用を学ぶ前に、CでゼロからLRパーサーをコーディングしました。それは非常に教育的であり、それ以来、私は私が使用したすべてのプログラミング言語についてより良い理解と感謝を持っています。

しかし、すべてのプログラマーが宮城氏の車を高レベルで働かせることができるようになるまでに何年も何時間も苦労する必要があるとは言っていません。プログラミング作業の多くは知的であり、特定の言語またはツールでコーディングする機械的な作業ではなく、ソフトウェアが何をする必要があるかを決定します。

その知的な仕事は、賢さ対愚かさはさらに重要です。

ジェームスララスの優れた「支出ムーアの配当」からの引用（強調を追加）：

30年前、Bill GatesはAltair Basicのプロンプトを「READY」から「OK」に変更して、5バイトのメモリを節約しました。今日、開発者がプロ​​グラムのこのレベルの詳細に気づくことは考えられず、心配することは言うまでもなく、当然のことながら、この規模の変化は今日では目立たないので... 今日のシステムを作成する方法はありません 4Kのメモリを搭載したマシンで（必要な）職人の手作業で作成されたプラクティスを使用しました。

フレームワークを使用すると、難しい問題を解決するために必要なスキルを回避したり、深い理解を回避したりできると言うのは、おそらく誤解を招くと思います。代わりに、今日の複雑なシステムを構築できる唯一の理由（その複雑さは困難な問題を生成し、深い理解を無視する可能性があります）は、フレームワーク（および高レベルOOガベージコレクション言語、および状況依存ヘルプとIDEオンザフライの構文チェック、およびプログラマーの口がきけないと批判されることがある他のすべてのソフトウェア開発の進歩）。

フレームワークは素晴らしいです。しかし、内部にあるものを知る必要があります。したがって、問題は、基礎となるシステムに関する十分な知識がなくても、プログラマーがフレームワークに頼りすぎていることです。

やや時代遅れの例はMFCです：プログラマーはWindows APIの代わりにMFCを使用することで多くの時間を節約できますが、APIの知識がなければ（つまり、生のAPIで実際の作業の背景があることを意味します）、彼らはしばしば立ち往生します。典型的なMFCプログラマーはWindows APIの知識を持っていたため、ほとんど起こりませんでした。

ただし、.NET上のWindows Forms では、カプセル化とオブジェクトモデルが優れているため、プログラマは、別のWindows APIラッパーを使用していることをほとんど無視できます。そのため、立ち往生する可能性は低くなりますが、それが起こると傷つく可能性があります。

残念なことに、市場投入までの時間は常に短く、プロジェクトはますます複雑になるため、プログラマーは深く掘り下げる時間がありません。それはソフトウェア業界の悲しい状態です...

必要な場所にスマートを配置します。建物の上部からボールを​​落とすメカニズムを設定するために、量子力学とニュートン物理学を理解する必要はありません。ソフトウェアのすべての新しい層がなければならない最後の上に構築し、定型を削除する便利なアプリケーションの構築から。

フレームワークの背後にある「もの」を必要とする、または知りたい人は、フックまたは詐欺師によって調査および調査します。

いいえ、まったくありません。フレームワークは、基本的にはサブルーチンライブラリとテンプレートの組み合わせであり、2つの実証済みのプログラマーツールです。「貧しい職人は彼の道具を非難している...

...そして、フレームワークを使用して非難する貧しい労働者がたくさんいます。

ソフトウェアを構築するとき、フレームワークは時間を節約します。ソフトウェアの構築を学ぶとき、フレームワークは理解の邪魔になります。

この問題は、主にコンピューターが非常に強力になったためだと思います。ほとんどのプログラマーにとって、「基本に立ち向かう」という理にかなった理由はもうありません。同じことをするのに時間がかかるだけで、実行時には意味のある違いはありません。それを解決する唯一の方法は、js1kのような競争のように、人為的な制限を導入することです。

おそらく、学校には、スペースと時間の強い制限の下でプログラムを構築しなければならない専用のテーマ「最適化されたデザイン」が必要でしょうか？

いいえ、フレームワークを学習すると、プログラマのスキルが向上します。フレームワークは、プログラミング言語の拡張です。一部の言語はすでにフレームワークベースです。私はPHPとJavaの両方を使用しています。PHPには、テンプレートエンジンのようなフレームワークが必要な場合があります（時々）。Javaはフレームワークを必要としません（ほとんどの場合）。すでに多くのメソッドとライブラリがあります。

ほとんどのフレームワークには、プログラマが何度も使用する関数があります。

ここで悪魔の擁護者を演じているように思えますが、フレームワーク（とにかく「良い」もの）は、実際にはプログラマーの教育を促進するのに大いに役立つと思います。適切に設計されたフレームワークは多くの問題を解決します。フレームワークを使用することにより、プログラマはどの問題がどのように解決されているかを理解することができます。私の考えでは、フレームワークはプログラミングのベストプラクティスの結晶化である（またはそうあるべきです）ため、プログラマーに例を挙げて教えることができます。