ルール13雪崩を起こした小石を探せ
ぼくが「コードを書くことってのは、実はデバッグすることなんだ」と言ったら、きみは悲しげに首を振って、「だよなー、あんたの言う通りで間違いない。分かってんじゃん」みたいな感じのことをつぶやくだろう。
まあ、実際はそんな会話は起こらず、誰もそんな風な言い方はしないんだけど。でも、前提になっている話には、間違いなく同意することだろう。アイデアを、完全に動作する実装にまで持っていく場合、「キー入力する」段階よりも、「動作するところまで持っていく」段階に相当多くの時間を費やすことは、避けられない。極端な状況(例えば、アイデアが単純で、かつ信じられないほどの幸運の連続に恵まれた場合)を除いては、コーディングよりもデバッグに多くの時間を費やすことになる。こんなのは分かりきった話なので、滅多に語られることがない。
ここで、ひねりを加えよう。
コードを書くことが実はデバッグすることなのは、ご存知の通り。でもその話は、コーディングのプロジェクトに対するアプローチ方法にどう影響するだろうか? コードを書くことが実はデバッグすること、すなわちバグを取り除くことなのは承知しているとして、そんな状況にどう取り組むつもりなんだろう?
「バグの少ないコードを書く」というのが、1つ明らかな答えだ。その話は本書の他の部分で扱っているので、今は脇に置いておく。今回のルールは、「デバッグしやすいコードを書く」という、別の話について書かれている。
バグのライフサイクル
ここで一歩引いて、デバッグとは実際には何なのかについて考えてみよう。バグのライフサイクルには、4つの基本的な段階がある。
- バグが発見される──問題を発見する。
- 次に、バグが診断される──異常な挙動の原因を調査して明らかにする。 ...
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.