コーディング標準で回避できるバグ[終了]

コーディング標準がバグを減らすのに役立つという主張を裏付ける統計（または推定）を探しています。ハードナンバーはいいと思いますが、私はそれを見つけることをあまり見ていませんでした。さまざまなオープンソースプロジェクトのバグ追跡も検討しましたが、必要なものを見つけるのにあまり成功していません。誰かが私がこれを見つけることができるかもしれない場所を知っていますか？それとも、より良いコーディング標準で回避されたかもしれないバグがあったオープンソースプロジェクトに貢献している人はいますか？

コーディング標準だけでは、バグを減らすことはできません。健全なソフトウェア開発プロセスの一部としてのコーディング標準は、バグを減らします。

以下は、健全なソフトウェアエンジニアリングプロセスが欠陥削減に及ぼす統計的影響を調査する2つの論文です。これらを出発点として使用できます。

• 1987年以降の経験に基づいたソフトウェアエンジニアリングの改善点を調査するソフトウェア障害削減トップ10リスト
• PSP Data Processの重要な分析。PersonalSoftware Processから収集された統計と、ソフトウェアエラーの一般的な原因に対するPSPの影響を調査します。

「標準」のコーディング...標準化できる開発分野はたくさんあります。命名標準などのコーディング規約について話しているのですか？それとも、TDD / BDD、CIなど、より深いものについて話しているのでしょうか？

CIがテストの合格と適切なコードカバレッジを実施する「テストファースト」方法論を順守することで、クライアントが発見するバグの数を減らすことができます。開発者とQAの両方による自動テストは、一般にフィードバック時間が非常に短いため、バグを見つけるための比較的「安い」方法でもあります。約45秒間の単体テストを実行することで、自分が書いたと思ったものを書いていないことがわかります。数時間の統合テストでは、物事をつなげることが計画通りに進まなかった場所を見つけ、エンドツーエンドおよび自動化されたUIテストにより、ソフトウェアの機能障害を非常に高いレベルで迅速に見つけることができます。

また、回帰を防ぎます。バグを見つけました。動作が発生しないことを証明するテストを作成し、テストに合格するまでコーディングします。これで、これ以降、バグが二度と問題にならないことを確認するテストができました。私の経験では、これは新しいバグの主な原因です。1つの問題を修正すると別の問題が発生し、開発者が修正プログラムをテストしても、現在破損している他の状況をカバーできない場合があります。かつて働いていたものを壊すことは、クライアントにとって大きな危険です。

最後に、この方法論の一部として構築するこの自動化されたテスト構造は、文字通りすぐにソフトウェアの新しいビルドをリリースできる環境を非常に簡単に提供します。「ねえ、あなたが修正したばかりのバグがいくつかの本当の頭痛の種を引き起こしている。いつ新しいバージョンで準備ができているのか？」「ああ、ビルドサーバーがダウンロードページへの公開を終了する約5分後に」をクリックします。

変数名などの標準化など、基本的なコーディング規則に関する限り、そのほとんどはあまり役に立たず、苛立たしいことがわかりました。これらは、「選択できるものが非常に多いため、素晴らしい」標準の一種です。PascalCased識別子とcamelCased識別子の違いとしてあなたが知覚するものは、他の誰かが考えているものではないかもしれません。主要なアンダースコア、名前の長さ制限（またはメソッド/フィールド名がストーリーを伝える要件）; コンパイラーによって強制される規則または言語固有のライブラリコードで一般的に見られる規則以外に、現代のIDEは、特定の環境で使用するかどうかなど、変数または関数について知っておく必要があるすべてを伝えることができます状況。さらに、コード規約チェックを実行すると、多くの場合、できない、またはできないコードに関する問題が返されます。異なる標準セットを使用したサードパーティライブラリ、またはネイティブ言語の標準ではなくWin API命名標準に準拠する可能性がある相互運用コードなど、変更したい場合。最終的には、コードに残骸を追加して、コード内の残骸を無視するようツールに指示します。

すべてのSQLインジェクションの脆弱性は、コーディング標準で防ぐことができた欠陥です。SQLインジェクションの脆弱性に関する統計は入手可能です。

すべてのバッファオーバーフローの脆弱性は、コーディング標準で防ぐことができました。それらの統計もおそらく利用可能です。