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

19章リズム

最初に立ち戻ろう。整頓するのは、将来システムの振る舞いを変更するときに、それを簡単にするためだ。将来の変更を簡単にするのは、それに価値があると思っているからだ（異論があると思うので、経済性の話はあとでするつもりだ）。さて、ここでは何を議論すべきだろうか？ そう、つかの間の休息を取ってからつらい仕事に戻るべきか、それとも何時間もずっと整頓するべきかだ。

整頓管理術の1つは、リズムの管理だ。以前の章で出たこの図（図19-1）では、整頓を小さなバッチにするよう勧めた。

図19-1　構造の変更をまとめるか分けるか

振る舞いの変更の前に続いている構造の変更は、1つがどれくらいの時間を表しているだろうか？

さて、ソフトウェア設計はフラクタルだ。なので、どんな時間軸にもなりうる。だが、本書の目的を踏まえ、1つのソフトウェア設計の時間軸を取り上げる。それは個人の範囲にとどまるソフトウェア設計だ。つまり、数分から1時間くらいまでだ。振る舞いを変更する前に1時間以上整頓するようだと、実現したい振る舞いの変更に必要な最小の構造変更を見失っている可能性が高いことを意味する。

もしくは、振る舞いを変更する前に何時間も整頓できるほど、コードがひどい可能性もある。そうだとしても、その状況は長くは続かない。ソフトウェア設計は「道を舗装する」傾向が強いのだ。

こんな話を聞いたことはないだろうか。ある大学がたくさんの建物を造った。計画者は、それを結ぶ歩道をどこに造るか考えていた。だが、そこで経験にもとづいて注意深く推測するのではなく、建物のあいだのエリアに芝生を植えたのだ。 ...