攻撃的プログラミングは、ソフトウェアのバグを隠したり回復しようとしたりするのではなく、プログラムを迅速かつ目に見える形で失敗させることでソフトウェアのバグに対処するソフトウェア開発の哲学です。 [ 1 ] [ 2 ]目標は、予期しない内部エラーは実行中のソフトウェアによって許容されるのではなく、プログラマによって修正されるべきであるという前提のもと、開発およびテスト中にバグを明らかにさせることです。
このアプローチは、エラー処理戦略であるため、防御的プログラミングの一分野とみなされます。しかし、デフォルト値を使用したり、劣化した状態で実行を継続したりすることでバグを隠蔽する可能性のある防御的手法とは対照的です。攻撃的プログラミングでは、アサーションなどのツールを使用して、無効な状態が検出された際にプログラムを即座に停止させ、問題の原因を特定して修正しやすくします。
誤りの区別
攻撃的なプログラミングの前提は、プログラムの防御ラインの外側から発生する、たとえ発生確率が低くても予測可能なエラーと、すべてのソフトウェアコンポーネントが期待どおりに動作すれば発生しないはずの内部エラーを区別することにある。
対照的な例：
バグ検出戦略
攻撃的なプログラミングは、意図的に失敗するように設計することで、プログラマーの前提を覆すことを目的としている。エラーメッセージを表示することは、二次的な目的となる場合もある。
戦略
- 不要なチェックは行わない：他のソフトウェアコンポーネントが仕様どおりに動作することを信頼し、未知の問題を隠蔽しないことが基本原則です。特に、一部のエラーは（プログラミング言語や実行環境によっては）プログラムをクラッシュさせることがすでに保証されている場合があります。例えば、ヌルポインタの逆参照などが挙げられます。そのため、プログラムを停止させる目的でヌルポインタのチェックは不要です（ただし、エラーメッセージを表示するために使用できます）。
- アサーション（無効化可能なチェック）は、ソフトウェアコンポーネント間の設計契約など、本来チェックする必要のない事項をチェックするための推奨される方法です。
- フォールバックコード（リンプモード）とフォールバックデータ（デフォルト値）を削除します。これらは、メイン実装の欠陥を隠蔽したり、ユーザーの観点からソフトウェアが最適に動作していないという事実を隠蔽したりする可能性があります。実装されていない部分は、テスト駆動開発のどの段階においてもユニットテストの失敗によって発見できないため、工場出荷時受け入れテストの一環として特に注意を払う必要がある場合があります。
- ショートカットコードを削除する（ストラテジーパターンを参照）：汎用コードがほとんど実行されない場合、簡略化されたコードパスによって、より汎用的なコードパス内のバグが隠蔽される可能性があります。両者が同じ結果を生成するはずなので、簡略化されたコードパスは削除できます。
参考文献
- ↑ 「攻撃的なプログラミング」。Cunningham & Cunningham, Inc. 2016年9月4日取得。
- ↑ Broadwall, Johannes (2013年9月25日). 「攻撃的なプログラミング」 . Thinking Inside a Bigger Box . 2016年9月4日取得。
