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

5章読む順番

　

想像してみてほしい。今あなたは何らかのファイルを読んでいる（ソースコードがファイルに属するかどうかは、また別の機会に議論しよう）。ファイルを最初から最後まで読んで、その最後にようやく欲しかった情報を見つける。先にこの情報があれば、残りの部分の理解に役立ったはずだ。

ファイル中のコードを読み手（それぞれの書き手にたくさんの読み手がいることを忘れないように）が遭遇したいと思う順番に並べ替えよう。

あなたは読み手だ。ただ読む。それで理解できるのだ。

同時に他の整頓をする誘惑に負けないこと。読んでいるうちに、理解や変更を必要以上に難しくしている点に気づくことがあるかもしれない。そこはあとで時間を取ろう。もしくは、今はそこを整頓して、あとで読む順番を入れ替えよう。混ぜてはいけない。

いくつかの言語では、要素の宣言順を慎重に扱う必要がある。つまり、関数Aと関数Bの順番を入れ替えると、違う実行結果になることがある。そのような言語では注意が必要だ。ファイル全体の順番を入れ替えるのではなく、読み手にとっていちばん関係のある部分だけを整頓するほうがよいかもしれない。

要素の並び順に完璧なものはない。最初に基本的な部分を理解してから、それがどう組み合わされるのかを理解したいときもある。最初にAPIを理解してから、実装の細部を理解したいときもある。あなたは読み手なのだから、自分の判断と（直近の）経験を活かしてほしい。あなたならどのような順番で遭遇したかっただろうか？ その順番を次の読み手に贈るのだ。