離れて考える事について（バス内デバッグ）
昨日は、久々に Java でのコーディング。正規の処理の実装は比較的簡単に終わったけど、例外処理の実装で手間取る。やはり例外処理なので考慮しないといけない例外の状態を数え上げ整理するだけでも大変だし、テスト用のデータを用意するのも面倒だ。結局テストを行うも、中々思うような結果ですに悪戦苦闘。実装が悪いのか、テストプログラムが悪いのか、テストデータが悪いのか。何とかメソッドの一部を改変して、目的の結果を得るが、なぜそうなのか全く納得できず、気持ち悪いのです。再びテスト続行。・・・・・
それで以って結局、終バス*1の時間になったので一旦終了。終バスに乗り疲れていたので眠ろうとしたけど、さっきの事が気になるので、何時の間にか思考実験ならぬ、思考デバッグを開始。頭の中に入っているソースコードを追いながら、変数の挙動を頭の中で計算してみる。なぜかしら、バスが終着のＪＲの駅につく頃には、大体何が問題で不可解な挙動の原因か目処がつく、先ほど試してみたけど。30分も掛からずに無事にデバッグ完了。
こうした事も今に始まった話ではなく、何度も何度も経験しているんだけど、ついついまたやってしまう。やはり思考実験とプログラミングでは使う頭の部分でも違うのだろうか。思考デバッグの場合は頭の中でポイントになる部分だけ押さえて掛かっているせいなのかな。
XPなどのアジャイル系のソフトウェア開発プロセスではテストファーストやテスト駆動を推奨してややもすると設計を簡素にしてしまう傾向があるが、本当にそれだけで良いのかなと思う。*2 難しい話だ。何が状態変数でどのように変っていくのか。状態遷移図でもちゃんと書いて調べれば案外と早い話かも知れない。
昔読んだ吉川英治の三国志に諸葛孔明が魏の郝昭が４千の寡兵で守り難攻不落と化した陳倉城を２０万の大軍で攻めあぐねて泥沼にはまった時、部下の姜維から「離」という事を献策され、悟る事があり事態を打開した話があった。終バス内で思考デバッグを行うたびに思い出す話である。
