テスト駆動開発者は三周目に死ぬのか

おかざわ それで、2009 年のオブラブ*15で発表されてた資料*16を見せて頂いて疑問に思ったのですが、TDD で開発したシステムが死ぬというのは、アーキテクチャ的に死ぬということでしょうか？

和田 ボトムアップで設計したものがアーキテクチャ的にどん詰まりになるということを言っています。 例えば、小さい部品を組み合わせてテストコードもちゃんと動いてるんだけど、テストコードは基本的にシングルスレッドの世界として書いてしまうことが多いですよね。

マルチスレッドで動かないとか、いざ本番で実際のリクエストに晒してみるとパフォーマンスが悪い、といったことが出てきてしまうので、「ちゃんとアーキテクチャを事前に設計すべし」という意見が出てきたりするんです。

テスト駆動開発やアジャイル開発、オブジェクト指向設計の文脈でよく話題になったり、批判されることでもあるんですけど「高いレベルのメンバーじゃないとできません」という意見がありますよね。

ペアプロ時もそうなんですけど「暗黙の設計」は、あります。

どうしても、個々人の差とか、どのぐらい設計のゴールが見えて TDD やっているのかというところは、やはり経験の差だとか能力の差が出てくるところではあります。

その上で、ではなぜ TDD をやっているかというと、作っていくうちに最初思い描いていたゴールから微調整が必要だとか、やってみて初めてわかることが多いんですね。

最初からきちんと設計してその通りに実装すれば上手くいくかというと多分そうではないし、でも無から完全にボトムアップで組み上げていったら、たぶん全然違うところへたどり着いてしまう。その中間に良い設計というのがあるんじゃないんですかね。