「デバッグルール(isbn:4891004398)」
という本がある。中で示されている例は、ソフトウェア開発というよりは電子回路な話だったりするわけだが、デバッグの本質は変わらないので、一読をお勧めする。といっても、内容自体はその帯にも書いてあるとおり、「当たり前」のことである。デバッグは問題解決プロセスそのものであり、ソフトウェア開発や電子回路に留まらず、何かの問題を解決するときには同じように考えなければならないからだ。
この本で挙げられている9つの原則を書き出してみよう。
- システムを理解する
- わざと失敗してみる
- 考えるのをやめて観察する
- 分割して攻略する
- 一度に１つづつ変える
- 履歴をつける
- 電源を確認する
- 新しい視点でものを見る
- あなたがしなければ問題は解決しない
極めて当たり前に関わらずなかなかできないことばかりである。何故できないかといえば、人は面倒くさがり屋であるのと同時に、自分がおろかであると認めたがらないものだからだろう。面倒くさがってマニュアルや仕様書をしっかり読まなかったり、突き詰めて考えなかったり、そんなはずはないと思い込んで違うところばかり見てたり、いっぺんに解決しようとしたり、メモを残さなかったり、そもそも問題自体から目をそらしてみたり、する。別に人のことを責めてるわけではない。昔の自分の経験が脳裏に蘇ってきて苦笑いが浮かぶと同時に今でも耳が痛い。今でも戒めておかないと容易く陥る罠ばかりである。
TDD(テスト駆動開発)の良いところは、この原則の一部の実施が義務付けられているところではないかと思う。強制はできなくとも単体テストツールやリファクタリングのような手法によって実施可能になっている。
たとえば、システムを理解しているということは、さまざまなシステムが動きについての事前条件と事後条件を具体的かつ正確にあげられるということである。TDDでは、まずこの具体例を設定するところからはじめる。
もちろん、TDDでもタコな具体例しか挙げられなければ、タコなシステムしかできない。具体例を選ぶ場合は追加する予定の処理がなければ確実にこけるような例を選ぶことが望ましい。分割して1つづつ攻略していくという原則はここでも守られなければならない。いっぺんにテストを書いても良いが、一歩一歩進めていったほうが確実である。これらの原則は意識して実施する必要がある。
新しい視点や思い込みの排除はTDDだけでは無理である。それゆえにXPではペアプログラミングをおこなうことで、一人でやっていると陥りがちなこれらの罠を回避しているわけである。
TDDでデバッグが不必要になるわけではない。ある程度予測して予防的に穴をふさいでおくことができるだけで、実際に動かしてみて発見される漏れは当然存在する。しかし、デバッグの一部を前倒ししておくだけでも作業はかなり楽になる。TDDの一番大きな利点は「自分がわかってないこと」を早いうちに自覚できることであり、デバッグではそれが最も難しいことであるからだ。
