TBD (Tracer Bullet Development)
予定より1ヵ月早く、AmazonからPragmatic Programmer本2冊届きました。
まずは、「Ship It!」から。
目玉はTDDならぬTBDです。といっても別に目新しいものではありません。「古いやり方を、今風にまとめてみました」的な手法です。
1.システムオブジェクトを定義する
これはレイヤーを定義するということです。中の細かいオブジェクトは、この段階では無視します。後でシステムオブジェクトに、機能を追加していく際に、オブジェクトは細かくしていきます。システムの全てのオブジェクトを早い段階で定義しようとすると、チームメンバの多くの時間を使うことになるからです。
2.インタフェースを定義する
隣接するレイヤ間で、インタフェースを定義するミーティングを行います。最良のアーキテクチャは、"象牙の塔"の1人のアーキテクトが定義するのではなく、チームメンバ全員で考えます。このグループ・アーキテクチャ設計のスタイルには次のようなメリットがあります。
- チームメンバ、特に若手にとって、このミーティングが学習プロセスになる。
- みんなでアーキテクチャを作るので、システム全体の理解につながる。
- チームメンバがアーキテクチャに対して、強力なオーナーシップを持つことができる。
また、このミーティングをうまくやるためのコツがあります。
3.スタブを作る
決めたインタフェースにしたがって、スタブを実装します。スタブの中身は空っぽです。この状態でテストを書き始めることができます。
4.スタブを互いに会話させる
スタブの中に、他レイヤーとのやりとり部分を実装します。「サッサと実装してしまえばええやん」と思えますが、レイヤー間の齟齬を、事前になくしておくことは、結果として手戻りが少なくなり得をします。いわゆるレバレッジです。
