ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

ルール13雪崩を起こした小石を探せ

　ぼくが「コードを書くことってのは、実はデバッグすることなんだ」と言ったら、きみは悲しげに首を振って、「だよなー、あんたの言う通りで間違いない。分かってんじゃん」みたいな感じのことをつぶやくだろう。

　まあ、実際はそんな会話は起こらず、誰もそんな風な言い方はしないんだけど。でも、前提になっている話には、間違いなく同意することだろう。アイデアを、完全に動作する実装にまで持っていく場合、「キー入力する」段階よりも、「動作するところまで持っていく」段階に相当多くの時間を費やすことは、避けられない。極端な状況（例えば、アイデアが単純で、かつ信じられないほどの幸運の連続に恵まれた場合）を除いては、コーディングよりもデバッグに多くの時間を費やすことになる。こんなのは分かりきった話なので、滅多に語られることがない。

　ここで、ひねりを加えよう。

　コードを書くことが実はデバッグすることなのは、ご存知の通り。でもその話は、コーディングのプロジェクトに対するアプローチ方法にどう影響するだろうか？ コードを書くことが実はデバッグすること、すなわちバグを取り除くことなのは承知しているとして、そんな状況にどう取り組むつもりなんだろう？

　「バグの少ないコードを書く」というのが、1つ明らかな答えだ。その話は本書の他の部分で扱っているので、今は脇に置いておく。今回のルールは、「デバッグしやすいコードを書く」という、別の話について書かれている。

バグのライフサイクル

　ここで一歩引いて、デバッグとは実際には何なのかについて考えてみよう。バグのライフサイクルには、4つの基本的な段階がある。

1. バグが発見される──問題を発見する。
2. 次に、バグが診断される──異常な挙動の原因を調査して明らかにする。 ...