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


8

バグまたは欠陥のクラスターの存在について多くの主張があります。単純な検索は、例えば、複数の結果を明らかにする: 12345

しかし、引用された証拠はすべて逸話的であり、これを裏付ける具体的なデータは見つかりませんでした。私自身の経験はこれらの主張に矛盾しませんが、パターンがない場合でも人々はパターンを見るのが好きです(バグが均一に分散されてもクラスターが生成され、10箇所ではなく1箇所で10箇所のバグを修正する必要がある場合は覚えやすいでしょう)コードベース全体で無関係なもの)。

この現象が実際に存在するかどうかは本当に気になりますが、欠陥のクラスタリングが実際に発生していることを示す客観的または半目的的なソース(テスト、実験、研究など)さえ見つけることができませんでした。

もちろん、私はバグのクラスタリング仮説を良い習慣として想定しても問題ありません(たとえそれが間違っていても、それほど害はありません)。一方、具体的なデータは、それが発生する理由を明らかにする可能性があります。何故かといえば、(どんな理由であれ)ひどい頭痛がしているからでしょうか。または、コードの一部が難しいだけで、他の部分が簡単なためでしょうか?それとも、互いに嫌いな2人のエンジニアの責任の所でしょうか。

私の質問:欠陥クラスタリング効果は実際に存在しますか?この仮説によって最もよく説明される具体的な非逸話的なデータはありますか?


その理由は、1つのバグが他のバグを繁殖させる可能性があるためです。これは、コードが相互にリンクされているために発生します。そのため、テスターは多くのバグを見つけて満足している一方で、プログラマーがその1つのバグを修正するだけで他のすべてのバグがなくなっていることを知らないことがあります。
kirie

ここで@kirieに同意します。ある機能のバグは通常、他の機能にカスケード効果があるということです。テスターは、それらを別個のバグであると考えているかもしれませんが、実際にはすべて1つの問題から発生しています。さらに、人間はパターンを見つけるようにうまく設計されています。それが、私たちがすべてでそれを行う理由です。
マーシャルタイガース2016年

非常にまれに、どこかでランダムな情報のビットを上書きする可能性があるバグがあります。ソースコードにこの種のバグがあると、ソフトウェアは何億もの可能な方法で誤動作する可能性があります。
gnasher729 2016年

2
これは有効な質問であり、OPが「具体的な非偶発的データ」を明確に要求したため、閉じられるのは望ましくありません。しかし、これまでの答えはこれを提供していません。私はむしろそれが保護されており、反対票が投じられた研究へのリンクなしに答えたいと思います。
mattnz 2016年

@ gnasher729私はあなたが言及する情報のどのビットを上書きするのかわかりませんが、多くの機能が完全にテストされていないが、すでに何度も使用されている初期段階でDRY原理を使用する場合、これは一般的です。
kirie

回答:


3

手元にデータはありませんが、クラスタリングの仮説が真実であると確信しています。私の最良の推測は、これらの2つのケースが多かれ少なかれ頻繁に発生することです:

  • コードまたはアルゴリズムの一部が複雑で(おそらく、実装が必要以上に複雑である可能性があります)、元のプログラマーは、その複雑さのために自分のコードが何をするかを完全には理解していませんでした。

  • コードは十分にテストされていません

そして-もちろん-両方の組み合わせ。テストは難しいですが、複雑なコードのテストは桁違いに困難です。そして、特にコードが十分にテストされていない場合の複雑さの増加に伴い、私の経験では、コードの一部の潜在的なバグの数が過度に多くなっています。

したがって、特定のコードにいくつかのバグが見つかった場合、それはおそらくテストが不十分で複雑なコードであり、同じ領域でより多くのバグを見つける可能性が高くなります。


2

このような正式な研究がソフトウェア開発に存在することはめったにありません。おそらく、プログラミングは(機械との関連にもかかわらず)主に人間の努力であり、機械の努力ではないためです。

昨日、2つのSELECTステートメントとUNIONを含むSQLステートメントのバグを修正していました。JOINの単純なエラーのため、両方のSELECTが同じ結果を返していました。ただし、問題を修正すると、最初のバグによってマスクされていた別のバグが明らかになりました。


2

私の経験では:

クラスタリングは、作業が中断されたときに発生します。誰かがプロジェクトを離れたために、彼の作業が完全にテストされていない、またはおそらく完了していない、および/または結果が完全に理解されていないとします。

クラスタリングは、「悪いプログラマ」の問題のためにも発生します。5人が何かに取り組んでいて、そのうちの1人が標準以下だったとします。バグは彼の仕事に関連付けられます。

パレートの原則が適用されます(別名80/20ルール)。効果のおよそ80%は原因の20%から来ています。https://en.wikipedia.org/wiki/Pareto_principle この観察は、コンピューターの前にさかのぼります。


0

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

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

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


1
私が正規分布で私たちが推論を行うことができるかどうかはわかりません。コードユニットごとの欠陥密度を分析していると思います。以下のために任意の非一様な確率分布、我々はいくつかのユニットが他のものよりバギーになることがわかります。正規分布のような対称分布の場合、すべてのモジュールのちょうど半分が平均以上の欠陥密度になります!もちろん、これはすべてのユニットでバグのリスクが常に発生すると想定した結果です。ただし、この質問とは正反対であり、バグにより多くのバグが発生するのではないでしょうか。多分私はこの答えを誤解しました。
アモン

「ちょうど半分の...」はい、しかしそれは現在の文脈では価値がありません。申し訳ありませんが、私はあなたのアモンを理解できませんでした。「バグはより多くのバグを繁殖させる」という正確な語句に同意しません。私の指摘は、見つかったバグは[無視できない確率で]とりわけ運命づけられているということです。
Vlad
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.