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

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

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

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

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

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

バグのライフサイクル

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

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

Get ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.