ソースコードのバグクラスタリング

バグまたは欠陥のクラスターの存在について多くの主張があります。単純な検索は、例えば、複数の結果を明らかにする： 1、 2、 3、 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 この観察は、コンピューターの前にさかのぼります。

バグのクラスタリングにはパラドックスはありません。そして、私たちの認知バイアスは炎を扇動します。

ある時点での正規分布によると、コードベースの一部は、他の部分よりもバグがかなり多くなっています。新しいバグは、バグの多い部分で発見される可能性が高くなります。
したがって、修正しようとしている問題は、会社を設立する可能性が高いため、すでに破滅しています。

それは「不幸が単独で来ることは決してない」と同じです。