開発ツールがより強固で堅牢になったとしても、優れたコードを書くことは困難になっているようです。そのツールでさえも強力であり、コードの品質は向上していません。私は2つの重要な要素を思いつきます。時間は短く、プロジェクトはより複雑です。現在使用しているツールはより強力であるため、より複雑なコードを書く方が簡単ですが、計画する時間がないため、振り返らずにコードの品質が低下し、バグとメンテナンスが増加します。以前に複雑なコードを書いたわけではありません。もっと複雑なコードを書くということです。
私の質問は次のとおりです。より強力な言語とツールがあることを考慮してください。
私が考えるプロジェクトのタイプは、非常に複雑でビジネスロジックのあるエンタープライズアプリケーションです。「良いコード」の定義は個々のものです。「良いコード」の解釈にとらわれないでください。
回答:
それは中デマルコとリスターで述べたようにピープルいくつかの20ish年前に、失敗したソフトウェアプロジェクトの大半は、技術的な課題が、社会学的な問題にはない失敗します。これは、ツールがどれほど改善されたとしても、過去数十年間変化していません。
誤った管理、非現実的な期待、仕事にふさわしい人材を獲得できない、および/または仕事をさせないために、結果的に彼らを維持できない。ソフトウェア開発作業に適さない職場とツール。未処理の個人的な対立; 政治 ; これらは、プロジェクトが最初から運命づけられる可能性がある典型的な問題のほんの一部です。
良いコードを書くのが難しいのはなぜですか？
何十年も前よりも、今では良いコードを書くことは本当に難しいと私は確信していません。実際、マシンコードやアセンブリと比較して、現在主流になっているものはすべて、扱いやすくなっています。それをもっと生産する必要があるかもしれません。
それは言及要因、時間、複雑さのためだけですか？
はい、ツールのパワーが増加するにつれて、達成可能な複雑性は確かに増加しています（そして増加し続けています）。つまり、境界を押し続けます。私にとってこれは、その日の最大の課題を解決するのが30年前だったのと同じように、今日の最大の課題を解決することも同様に難しいように翻訳します。
OTOHはフィールドが非常に大きく成長して以来、30年前よりもはるかに多くの「小さな」または「既知の」問題があります。これらの問題は技術的には（もはや）挑戦ではありません（しかし）ですが、...ここで上記の格言に入ります:-(
また、プログラマーの数はそれ以来非常に大きくなりました。そして、少なくとも私の個人的な認識では、経験や知識の平均レベルが低下したのは、単に彼らを教育できる先輩よりもはるかに多くのジュニアが現場に到着しているからです。
方法論が正しく実践されていないということですか？
私見は確かではありません。DeMarcoとListerには、big-M方法論に関する厳しい言葉があります。彼らは、方法論によってプロジェクトを成功させることはできず、チームの人々だけが成功できると言っています。彼らが称賛するOTOHのsmall-m方法論は、現在広く知られている "アジャイル"に非常に近いものであり、広く普及しています（正当な理由でIMHO）。ユニットテストやリファクタリングなどの良い慣行は言うまでもありませんが、これはわずか10年前にはあまり知られていませんでしたが、最近では多くの卒業生でさえこれらを知っています。
非現実的な締め切りの下でのコーディングおよび技術的負債の処理に関連する問題は、ワインバーグ'71およびブルックス'72以来知られています。それ以前はオンラインで文献を掘り下げることは困難になりますが、同じことを言っている古いCDC、IBM、およびNASAのレポートがあると確信しています。
私たちは皆、「グッドコード」のための独自のアイデアとしきい値を持っていると思います。ただし、すべての原因となる多くの問題があります。
最終的には、「良い」または「ベスト」を追求するよりも、追求する方が良いと思います。そこに最高のコードを見た場合、それをそのように認識しますか？
良いコードを書くのが難しいのはなぜですか？
なぜなら、ソフトウェアはますます抽象層の上に構築されるからです。開発を簡単かつ迅速にすると主張する新しいテクノロジーはそれぞれ、開発者が理解する必要がある複雑さのレベルをもう1つ追加するだけです。現在、これらの抽象化は生産性に大きなメリットをもたらす可能性がありますが、隠そうとしていることを理解していないと、ソフトウェアがバグや品質の低下の影響を受けやすくなります。
現代のソフトウェア開発では良いコードは不可能ですか？
実際、それは不可能です。しかし、あなたがすでに聞いた理由はありません。
プロジェクトの大部分の範囲は、人間の脳の能力をはるかに超えています。人々が抽象化のアイデアを思いついたのはそのためです。つまり、枝の密度（処理する情報の量）が許容可能な割合まで減少するまで、詳細を隠し、抽象化ツリーを上に登っていきます。
複雑さの問題は解決しましたが、以前の大きな問題は解決していません。
まだ複雑すぎて処理できません。
高品質のソリューションを作成するためには、すべてを同時に見て理解できるようにする必要があります。それは、すべてのモジュールが大小の実装の詳細にあることです。一度にすべての不一致を確認し、考えられるすべてのシナリオのコンテキストで各コードを確認し、コードベース全体を同時に最適化します。
これを行うことはできません。
そして、できない場合は、高品質のコードを生成することは決してありません。
マネージャーはモジュールの散らばりを見ることができますが、モジュールごとの内部の問題と制限を知りません。
モジュールプログラマはローカルの制限を知っていますが、全体像のコンテキストでそれを最適化することはできません。
マネージャーとプログラマーの間（さらにはプログラマー間）で理解を伝える方法はありません。そして、たとえあったとしても、人間の脳の能力はそれを処理できませんでした。
努力を続けること（無駄な運動）を除いて、私たちにできることはほとんどありません。コードを多かれ少なかれ操作し続け、人生を楽しんでみましょう。
あなたの質問の前提を否定します。良いコードを書くのはこれまでになく簡単になりました。そのため、これまで取り組んできた問題よりもはるかに困難に取り組んでいます。
特定のベンダーを選びたくはありませんが、Windows 1.0とWindows 7を比較してください。後者には数千倍のコードが含まれていますが、クラッシュ間の平均時間が100倍に増加しています。Windows 3.1以降、Word文書にExcelスプレッドシートを埋め込むことができるようになっていますが、最近では実際に機能します。
「最近のダックタイピングとVMを使った子供たち」のセンチメンタリティに陥ることを望まずに、80年代に良いコードを書くのがどれほど難しいかわからないことをお勧めします：TINY、SMALL、HUGEメモリモデル、オーバーレイ、非レントOS呼び出し（シャダー）。すべての良い馬鹿。
現代のアプリケーションは、20〜30年前よりも複雑になっています。これは、その環境が豊富で汎用性が高いためです。
DOSプログラムでは、ユーザーからの次のキー入力を待機するタイトループに座ってから、対応するコードを呼び出し、次のキー入力の待機に戻るのが一般的でした。
マウスをまったく使用できない最新のアプリケーションには、深刻な説明の問題があります。また、ユーザーが入力した最新のエントリを表示するアプリケーションでRSSフィードが更新されている間、ユーザーが入力してマウスでクリックし、入力を続けることができるので、事態は任意の順序で発生します。
これらすべてのマルチタスクは、ユーザーからのキーだけを考えなければならなかったときよりも本質的にはるかに複雑です。それは本当に良いコードを書くことを難しくします。
開発者の観点から見て、マルチタスクプログラムをより使いやすくする方法を研究者が見つけたとき、これは緩和されるかもしれませんが、今のところ、それをうまくやろうとしているが、どうすればいいか分からないままです。それ。
ソフトウェアは、利用可能なプロセッサ速度、メモリ、ディスク、およびプログラマの時間を埋めるために拡大したように思えます。これは、ソフトウェアがより多くのことを達成するためだと断言できます。まあ、私はそれがもっと多くを成し遂げると確信していますが、肥大化を正当化するには十分ではありません。
覚えておく価値のある古代の科学の法則があると思います。
自然は真空を嫌う。
フランソワ・ラベラス（フランスの修道士と風刺家1494-1553）
実際、過去10年間で、優れたコード、つまり期待どおりに機能し、保守可能なプログラムを作成することが容易になったと思います。利用可能なツールはより優れており、ライブラリはより成熟して包括的であり、ハードウェアははるかに高速になっているため、最適化の手法を使用する必要はありません。
では、なぜ私たちはそうしないのでしょうか？
IMOの主な理由は、私たちが常に物事を悪用する方法と言い訳を探すことです。Windows実行可能ファイルを作成するような、昔ながらの簡単で退屈な方法ではなく、可能性の限界を押し広げ、PhotoShopのようなものをWebアプリケーションとして再作成する方法を探します。どうして？できるから。または少なくともそう思う。
誰かがエクスプロイトを書いたり、そうするために勉強したりしなかった最後の時は、アセンブリ（カーネルハッカーやASICの人を数えていない）にだまされていましたか？Cコアライブラリで発見されたバグの数 ほとんどありません。私が言っているのは、人々は優れたコードを書く能力があるということです。より良いツールと言語は、単に「必要」を減らし、「オプション」を増やします。私たち全員が本当にひどいコードを書くべきだと思うわけではありませんが、複雑な論理構造を考えると...誰もアセンブリにハッシュ配列を使って何かを書くことを夢見ていないでしょう。複雑な構造を使用する代わりに、ロジックを処理する「より良い」方法が必要でした。コードが美しい場合でも、アプローチがエレガントではない場合があります。私はそれがあなたが言及した問題に対処していると思う。良いコードは常に整理されているだけではありません。
優れたツールと応答性の高いコンピューターのおかげで、数年前（または数十年前）に比べて、単位時間あたりの最終製品の複雑さが大幅に向上すると予想されるからだと思います。そのため、アプリの複雑さは増し続け、合理的なレベルの生産性に関する私たちの仮定は増え続けています。
私が仕事をしている場所では、開発者はいつも急いでいます（顧客が望む時間よりも多くのものが常にあるため）。そのため、多くのコードブロックは最小限の編集でコピーされ、実際に理解するための努力は必要ありません。そしてもちろん、エラーが発生します。開発者が最適化したコードをコピーしたバグが修正されたのを見ましたが、最適化を有効にしたという仮定が彼がそれを置いていた場所に当てはまらないことに気付きませんでした。
これはすべて、内部（私たち自身の期待）と組織の両方の期待に帰着します。できる限り短い時間でできる限りのことをしようとしています。そして、必然的にエラーが発生します。
また、コンピューターの応答性により、迅速で迅速な編集、コンパイルおよびテストの実行が促進されます。昔（35年前のように）、ターンアラウンドは非常に遅かったので、コードを印刷し（ソースはパンチカードでした）、デッキを送信する前にコードの手動ステップスルーを行いました。これで、コンパイルを編集して実行するだけです。したがって、体系的なコードウォークスルーを介して発見した多くのバグは、代わりにキャッチするためにコンパイラおよび/または単体テストスイートに頼っています。
優れたコードの作成で人々はどのように悪化しましたか？
あなたが取る場合は、.NETやC＃などの言語、例えば、私はコーディングと主張するだろう（と私はそれが唯一のプラットフォーム/言語ではありません実現）も原因のVisual Studio内で多くの自動化にはるかに、はるかに容易になりました環境。
どちらかといえば、コーディングと開発プロセスをガイドできる非常に洗練されたIDEを持っているという単純な事実は、「良いコード」を簡単に達成できることです。
プログラマーは、ブラケットとブレースと改行を入力してメソッド呼び出しとクラス名を覚えるだけの時間を費やすのではなく、実際に良い構造を作成することに集中できます。
私の2セント。
はい、業界としての私たちは、良い方法論として知られていることを実践していません。参照：Steve McConnellのConstrux Software Software DevelopmentのLow Hanging Fruit。
コードの品質は良くなっていません
「良いコード」の解釈にとらわれないでください
偉大な論理的トートロジー。
人々は「良い」という定義を動かし続けるため、コードは良くなりません。
「良いコード」について議論することができれば、比較することはできず、「チャレンジ」であるかどうかを本当に決めることはできません。