設計が先？実装が先？
ソフトウェアのアーキテクトは難しい。のではなくて、作る前からアーキテクトを決定することが難しい。
難しいことをしようとすると失敗するのは世の常なので、世の常です。
「設計を先にする」ことは、絶対善でもなんでもありません。製造業から流れてきた技法の応用です。
数千年の歴史ある「建築設計」の技法により製造される製品・建築物と、ソフトウェアの製造手法は異なります。
何よりも、ソフトウェアはコンクリートと違って作り直しができるという断然有利な条件を持っています。
つまり「設計を先にする」必要は全くないのです。※定義はさきにしてね
実装から単体テストをつくる
実装をもとに単体テストを作成することはTDDの本意ではありません。
しかし、テスト技法を身に着けるために避けて通れない道です。通過点です。ですから、技法を身に着け、この手法を止めることが目標であることを忘れてはいけません。
単体テストから実装をつくる
実装から単体テスト眺めると、異様な数の「暗黙な入出力」を知ることになります。
グローバル変数、定数、ログ、ファイル出力、様々なものがあります。そしてこれを憎むようになるとテストドリブンの血が注入された証です。
この時点で美しいテストコードは、この「暗黙の入出力」が少ない、または明確に仕様に示されることが美しい状態であると気づきます。（美しい＝ルールが少ない＝例外が少ない）
そして、美しいテストコードの作成するためにはどういう実装をするべきかというアーキテクトが発生します。
これが第2段階の単体テストから実装の設計を考えることができるようになります。
ここで重要となるのは単体テストをもとに実装をリファクタリングする環境があるかという問題です。
このリファクタリングが許されていなければ、技法の経験を積むことができず、これから先に進むことが困難になります。
実装の超絶に速い人たちは、時間内にリファクタリングしてしまうので、勝手にこれを乗り越えていきます。
これが、現場でTDDの影の薄いクリティカルな原因です。「TDDは死んだ」
TDDをする
TDDの方式や例示などは、各書籍で超絶な人が紹介していますので、ご購読ください。
関数型デザイン R.C. Martin
ASCII DWANGO 2024
Lazyな設計
TDDの主目的は、アーキテクト設計をLazyにすることである。
実装の全体像が見えない場合に、とりあえず作ってみてから設計を検討していくのである。
実装の全体像が見えるのは高度な技法なので、原則Lazyに”しなければ”いけないのです。
ちなみに、設計をLazyにするのにTDDである必要は全くないのです。