■

Beautiful Codeという本を読んでるんだけど、色々面白いエピソードとか難しい話とかが載ってる(みたい。まだ、全部読んでない。)。28章として"美しいデバッグ"という章がある。その中で、系統だった方法(科学的手法って言うそうな)として次の手順が紹介されてた。

1. プログラムの失敗を観察する
2. 観察と矛盾しない失敗の原因についての仮説を立てる
3. 仮説を使って予測する
4. 予測を実験でテストして、さらに観察する
　a. 実験と観察が予測を満たすなら、仮説をさらに精緻なものにする
　b. 満たさないなら、別の仮説を立てる
5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す。

あぁ、これ俺の仕事の80%ぐらい説明してる。そして、1が手元で再現しないと3から始まったりするから絞り込めずに泣きを見ることが多い。そして次の文は、良く思う。

プログラマにとってはいろいろな機能に富んだデバッグツールを習うよりも、系統だったデバッグ手法の訓練をするほうが重要だと私には思えます。

デバッガは便利なんだけど、いろんなところでブレークポイントいれてごにょごにょやるよりも前に、コードをみて予測してピンポイントに値をチェックしたり確認を繰り返すことをやることのが早く原因にたどり着ける事が多い気がする。最近のツールは豊富な機能が備わってるので、全然違うのかもしれないけど。

Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly))