Tidy First? ―個人で実践する経験主義的ソフトウェア設計

18章バッチサイズ

統合してデプロイする前にどれだけ整頓すればよいのか。

まず、検討すべきことは2つある。

• どれだけ整頓すべきか？ 「整頓」を次の振る舞いの変更をサポートする構造的な変更ととらえるなら、次の振る舞いの変更をサポートするにはどれだけ構造的な変更が必要かという話になる。整頓ははるか先の未来を見据えたものではない。整頓は当面のニーズに対応するものだ（これについては「21章　先に整頓、あとに整頓、改めて整頓、整頓しない」で詳しく触れる）。
• どれだけの整頓なら統合してデプロイすることが簡単になるか？

16章では、整頓と振る舞いの変更を混在させなかった。しかし、整頓を一気にまとめて行うか、すべて別々にするか、それともそのあいだのどこかという点において、なお議論の余地はある（図18-1）。

図18-1　構造的変更をまとめて行うか別々にするか

これによって私たちはトレードオフを迫られる。いわゆるゴルディロックスのジレンマだ†1。何のコストを比較検討すれば、バッチあたりの整頓が少なすぎるのか、多すぎるのか、いくつくらいならちょうどよいのかを判断できるだろうか？（図18-2）

[†1] 訳注：3つの選択肢があると、人間は無意識のうちに真ん中の選択肢を選んでしまう傾向のこと。

図18-2　バッチあたりの整頓のトレードオフ

バッチあたりの整頓の量を増やした場合に上がるコストを図18-3に示す。

図18-3　バッチに合わせて上がるコスト

含まれるのは以下だ。 ...