ソースコードのバグクラスタリング
バグまたは欠陥のclustersの存在について多くの主張があります。単純な検索で複数の結果が明らかになります。例： 1 、 2 、、 4 、 5 。
しかし、引用された証拠はすべて逸話的であり、これを裏付ける具体的なデータは見つかりませんでした。私自身の経験はこれらの主張に矛盾しませんが、パターンがない場合でも人々はパターンを見るのが好きです（バグが均一に分布してもクラスターが生成され、10箇所ではなく1箇所で10箇所のバグを修正する必要がある場合に覚えやすくなります。コードベース全体で無関係なもの）。
この現象が実際に存在するかどうかは本当に気になりますが、欠陥のクラスタリングが実際に発生していることを示す客観的または半目的的なソース（テスト、実験、研究など）は見つかりませんでした。
もちろん、私はバグのクラスタリングの仮説を良い習慣と仮定しても問題はありません（たとえそれが偽であったとしても、それほど害にはなりません）。一方、具体的なデータは、それが発生する理由を明らかにする可能性があります。それはそれらの日のために人は（何らかの理由で）ひどい頭痛を持っているのですか？または、コードの一部が難しいだけで、他の部分が簡単なためでしょうか？それとも、互いに嫌いな2人のエンジニアの責任の所でしょうか。
私の質問：欠陥クラスタリング効果は実際に存在しますか？この仮説によって最もよく説明される具体的な非逸話的なデータはありますか？
手元にデータはありませんが、クラスタリングの仮説が真実であると確信しています。私の最良の推測は、これらの2つのケースが多かれ少なかれ頻繁に発生することです：
コードまたはアルゴリズムの一部が複雑で（おそらく実装が必要以上に複雑である可能性があります）、元のプログラマーはその複雑さのために自分のコードが何をするのか完全には理解していませんでした。
コードは十分にテストされていません
そして-もちろん-両方の組み合わせ。テストは難しいですが、複雑なコードのテストは桁違いにはるかに困難です。そして、複雑さが増すにつれて、特にコードが十分にテストされていない場合、私の経験では、コードの一部の潜在的なバグの数が過度に多くなります。
したがって、特定のコードにいくつかのバグが見つかった場合、それはおそらくテストが不十分で複雑なコードであり、同じ領域でより多くのバグを見つける可能性が高くなります。
このような正式な研究がソフトウェア開発に存在することはめったにありません。おそらく、プログラミングは（機械との関連にもかかわらず）主に人間の努力であり、機械の努力ではないためです。
昨日、2つのSELECTステートメントとUNIONを含むSQLステートメントのバグを修正していました。 JOINの単純なエラーのため、両方のSELECTが同じ結果を返していました。ただし、問題を修正すると、最初のバグによってマスクされていた別のバグが明らかになりました。
私の経験では：
クラスタリングは、作業が中断されたときに発生します。誰かがプロジェクトからシフトされたため、彼の作業が完全にテストされていない、またはおそらく完了していない、および/または結果が完全に理解されていないとします。
クラスタリングは、「悪いプログラマ」の問題が原因で発生します。 5人が何かに取り組んでいて、そのうちの1人が標準以下だったとします。バグは彼の仕事に関連付けられます。
パレート原理が適用されます（別名80/20ルール）。効果の約80％は原因の20％に起因します。 https://en.wikipedia.org/wiki/Pareto_principle この観察はコンピュータの前にさかのぼります。
バグのクラスタリングにはパラドックスはありません。そして、私たちの認知バイアスは炎を煽ります。
正規分布 によると、任意の時点で、コードベースの一部は他の部分よりもかなりバグが多いです。新しいバグは、バグの多い部分で発見される可能性が高くなります。
そのため、修正しようとしているのはすでに運命づけられており、会社を持つ可能性が高いです。
それは「不幸が単独で来ることは決してない」と同じです。