■ デバッグ指向のススメ 
■バグの発生は必然
バグの発生は予定外の出来事ではありません。よほど小規模のプログラムでない限り、ソースコードが一発で不具合なく動くことはほとんどありません。つまり、デバッグ作業というものは、ソフトウェア開発において重要なステップなのです。実際、大抵のソフトウェア開発では、コーディングそのものよりもデバッグに費やす時間の方が多いことが多いのではないでしょうか。つまり、このデバッグをいかに効率よく進められるかということが、ソフトウェア開発の効率を左右するといっても過言ではありません。
■デバッグ効率をいかにあげるか
では、デバッグの効率はどのようにすれば改善できるのでしょうか？項目としてあげるとすると、
(1)バグのパターンを知り、解析・切り分け方法を習得する
(2)デバッガ・各種ツールを使いこなす
(3)デバッグ用のコードを埋め込んでおく
(4)デバッグしやすいコードを書く
といったところでしょうか。
細かい点は追々追加していきますので、今回はデバッグ指向の一例として、契約プログラミングについて説明します。
■契約プログラミング
契約プログラミング(DBC:Design By Contract)という言葉をご存知でしょうか。プログラムのコード上に、満たすべき条件を埋め込んでおき、違反があれば検出するというものです。最も基本的なものにassertがあります。ご存知のように、条件をチェックして、不一致であればログ出力後、abortするものです。
■ バグだらけーバグだらけー 
自分でバグを仕込みそうだなと思う部分があれば極力富豪プログラミングした方がいいなと思う今日この頃。
ていうか自分はそんな感じのスタイルなんですが。重いすねゴメンね。
会社でバグだしまくる人とか、なんで出すんだろうって考えたら、状態が変更されたときだけチェックする仕組み（差分的プログラミング？）になってて至る所でそのチェックが甘いために起きるのがわかった。
その人がまったくプログラムできないかというとそうではないんだけど、そういう脇の甘さがバグに繋がるんだろうなーと思う。
ただ、一昔前だとCPUも遅いし毎フレーム全部の処理を更新するなんてのは重いから、ダーティフラグが立ったものだけ動かすとかは普通だったと思うし、今でもPyGameとか描画が重いから動いたスプライトだけ調べて更新箇所だけ更新するっていうやり方を推奨しているのはいくつもあるので否定はできないスタイルだと思う。
だからといって1000x1000x1000の3重ループ作って
「いやぁこの処理使うとたぶん重いんだよねー。処理落ちするかも」
とかパフォーマンスも調べずに（調べなくてもわかる）関数を提供するクソプログラマーはぶっ殺しますよ。
富豪的プログラミングってのは原始的な組み方だと思うので後で最適化だってしやすいはず。
もしかしたらしやすくないかも。
