TL;DR
- 大きな設計変更ではなく、その前にある小さな変更から手を付け、2 つのサブクラスのコンストラクタを親クラスに引き上げた。
- TDD のステップの大きさ（歩幅）に正解はなく、窮屈なら大きく、大きすぎるなら小さくすればよい。
内容
本章でやったこと
大きな設計変更に取りかかる前に、その手前の小さな変更に着手した。
- 2 つのサブクラスのコンストラクタで異なる部分を、呼び出し側（Factory Method）に移して、コンストラクタどうしを近づけた
Francに行ったリファクタリングを、Dollarには大きなステップで一気に適用した- まったく同じ内容になった 2 つのコンストラクタを、親クラスに引き上げた（Pull Up Method）
次は、残った times メソッドを削除する。
作業中に気づいた修正をどうするか
教科書的な答えは、「今の作業を止めないために、修正は後回しにすべき」である。しかし Kent Beck は次のように考えている。
ちょっとした割り込み（修正）を楽しもう。ただし、ちょっとしたものに限る
割り込みにさらに割り込むことはしない
歩幅の調整
TDD では、必ずしも細かいステップ（歩幅）で進む必要はない。窮屈だと感じるならステップを大きくし、大きすぎると感じるなら小さくすればよい。ステップの大きさを決めるのは開発者（あるいは AI エージェント）であり、正しいステップの大きさというものは存在しない。
キーワード
自分の理解
ステップの大きさを適切に調整するには、経験が必要になりそうである。