回答:
ソフトウェアの欠陥の主な原因は解釈です。
機能の顧客の解釈は、設計者の解釈とは異なります。
デザイナーの解釈は、プログラマーの解釈とは異なります。
ほとんどの方法論は、この影響に対処する方法を発明しました。しかし、結局のところ、私たちは人間であり、完璧ではありません。また、多くの場合、時間的なプレッシャーがあり、ほとんどの方法論の魔法は、プレッシャーにさらされている間はしばしばスキップされます。
テストでは問題を早期に検出できるだけです。しかし、テスターでさえ人間であり、100％をテストすることは不可能です。宇宙が終わる前に解放したい場合。
ソフトウェアの欠陥の主な原因はプログラマーだと思います。
ただおかしいと言っているわけではありませんが、私が仕事で見た大きな問題の1つは、要件の収集が不十分であり、問題の領域に対する理解が不十分であり、プロジェクトの主要な欠陥と使いやすさの問題を引き起こしているためです。
その一部は、エンドユーザーの用語を学習/理解する意思がなく、誤解を招くことに起因します。
その一部は、あなたが何について話しているのか、なぜそれが重要なのかについての手掛かりを持っていない人々に、技術の話をプロセスの早い段階で行うことから来ています。
その最良の例は、質問/回答が文字でどれだけ長くなるかを把握しようとしているプログラマーの1人を耳にしたときです。データベースで使用するサイズフィールドを把握しようとしていることはわかっていましたが、これを要求する部門は、それが重要な理由であるか、スペースが重要であるかという最も霧のかかった理由ではありませんでした。それは明らかなように思えますが、彼らにとっては本当の啓示でした。
欠陥の主な原因は、不適切な管理です;）
真剣に、良い状態で働いている、過労、品質の削減、適切なツール、静かな労働条件などを求められていない開発者は、厳しい圧力の下で働いている人よりもバグが少なくなります。
また、管理者が悪い開発者を雇うと、バグの数が増えます。
悪い管理。
（免責事項：開発者を雇って管理することになっています）
主要な原因は1つも見当たりませんが、言及されていない原因の1つは、他のコードとの意図しない結合です。目に見えない副作用を持つコードを記述し、抽象化レイヤーを突破し、データについての仮定を行います（変数は使用せず、定数は使用せず、ユーザーからの入力は安全ではありません）。それ自体など。
開発プラクティスのほとんどは、私は、還元まで沸騰を研究することをNプログラムの複雑さは、少なくともあるので、O(N^2)おそらくO(k^N)。定義することNは読者の課題として残されていますが、ここでは循環的な複雑さなどを考えています。ロジックとデータをカプセル化すると、問題を区分化してNを減らす効果があります。
完全に理解せずに物事を急ぐ。機能要件または技術アーキテクチャを完全に理解せずにコードの記述を開始します。
プログラミングはほとんど自動的に行われ、自明であり、すでに頭の中で解決されているものを書き留めてください。実際には、コードが何をすべきかを正確に把握しようとするために、コードに多くのフレアが見られます。私はこれを何度も犯しました。
ソフトウェアエンジニアリングが本質的に複雑だからです。エッセイ「No Silver Bullet」はこれについて議論しています。
皮肉なことに、ここでの他の回答の多くは、そのエッセイの言語で「偶然に複雑な」トピックに触れていますが、実際には、ソフトウェア開発者が行うことのほとんどは「本質的に複雑」です。ソフトウェアは難しく、ソフトウェアにはバグがあります。私たちの仕事はそれに対処することです。
「発生しない」または発生する可能性が低いことを確認することができないのは大きな問題です。時には完璧は善の敵です。よく考え抜かれた例外階層の価値がなければ、いくつかの迅速で汚れた処理は、何もしないよりも常に優れています。私は巨大ですリリースビルドでのパフォーマンスへの影響が無視できるほど速く失敗する、アサートする、アサートを断念するのが好きです。すべての入力データを制御する高速でダーティな1回限りのスクリプトでさえ、通常はアサートと同等であるが常にオンのままである関数を使用して、クイック/ダーティなエラー処理を行います。私の経験則では、発生する可能性が低いか、発生しないと思われる場合、ユーザーフレンドリーなエラーメッセージで正常に失敗する必要はありませんが、少なくともエラーメッセージが表示されてすぐに失敗する必要がありますプログラマーに何がうまくいかなかったかについてのヒントを与えます。
編集：関連する便利な方法の1つは、主要なデバッグツールとしてアサートを使用し、デバッグセッションが終了した後もそのままにしておくことです。その時点から、コードベースには、関連するバグが再び発生するのを非常に困難にする組み込みの健全性チェックが行われます。これは、ユニットテストが難しいコードに特に役立ちます。