TDD wo xUnit

昨日は久々にドライバーになってコード書いた。AM15分、PM20分。ナビゲーターはうちのエース。(傍観者はid:vestige)

今回は意識して自分のやり方を観察してたけど、やっぱりTDDじゃなかったな。

• 作りたいものは二人で理解しているので、作り方の作戦を確認し合う。(30秒くらい)
• 時計見る。お昼までに30分あるので、食事前に終わりそう。作業場所へ移動。
• 今その機能がない、ということはどうやって試せるか考える。んで、実際試す。
• 改造開始。主処理(コールする側??)にテーマとなる2行を追加。コンパイルエラーを確認。まだ実装ないからね。
• 呼ばれる側のなにもない実装を書く。必要な引数を考えて、それが渡せるかどうかを確認するのため。コンパイルエラー確認→戻せない情報があったので戻り値の型を変更
• 中身を書き始める。実装の作戦を説明(10秒)。同じようなイディオム(今回はeachみたいなもん)を探して真似する。自分の書いたコードでも10年前のは暗記してないっぽい。途中で情報が足りないことに気付いてインターフェイスを変更し、コンパイラにうまくいくか聞いてみる。
• 音読しながら書き上げる。途中でいろいろ指摘してもらって、すんなり終わる。
• 改造後のコードを試す。まあ動く。動きを観察して、意外な点がないか探す。
• 想定外の挙動を見つけて、そうなる理由を話しあう。
• このケースの対応を決める。ずっと前に似たような問題を解いたことがあったのか、すんなりどうすればよいか思いつく。
• なにかがひっかかるけど、想定される範囲で問題がなくなってしまったので、ちょっと寝かしてみる。

AM終わり。

食事しながら、もっと昔に見た解き方を思い出す。なんでそっちの方が良いのかしばらくわからなかったけど、食事の終わりくらいに別の問題となるケースを思いつく。

PM開始

• 別の問題となるケースを説明する。理解してもらって、それが実験できる環境をつくる→確認できる。
• 新しいアルゴリズムを入れるのに必要な改造を説明する。
• 既存の関数のインターフェイスを変更したいので、プロトタイプ宣言を変更してコンパイルエラーを誘う。影響範囲はコンパイラに聞く。想像以上に小さくて驚く。
• 実装開始。まあAMと似たようなやり方ですぐ書き終わる。
• 今度はうまく動かない。
• 挙動から原因となる部分はあたりがつくので、それがわかるような変更をして、問題を絞る。
• 泣く泣くデバッガを起動する。負けた気分。でも特に新しくわかったことはない。
• 大昔に構造体のメンバにビット数を指定してたことを思い出す。
• やっと動く。問題の挙動との関係を話し合う。作ろうと思ったように作れたことを確認。
• 作ろうと思ったものが欲しかったものか確認。

かなり省略してますが、こんな雰囲気でした。一分間に何回実験してんだよ! って感じですが、小心者のチキンなのでしょうがない。
結論としては「現実逃避にはプログラミング」です。
#みんなのお母さんみたいな係はほんとは合わないんだよ。

あわせてよみたい。

ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集