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

16章分けて整頓する

今のところはプルリクエスト/コードレビューのモデルを使うと想定する（のちほど代替案について議論する）。整頓をどこに入れればよいだろうか？

以下は堂々巡りのひどい例だ。

1. 整頓を振る舞いの変更と一緒に入れる。
2. レビュアーはプルリクエストが長すぎると文句を言う。
3. 整頓を独立したプルリクエストに分けて、振る舞いを変更する前にプルリクエストを出す（たぶんこちらだろう）、もしくは振る舞い変更のあとに回す。
4. レビュアーは整頓のプルリクエストが無意味だと文句を言う。
5. 1に戻る。

整頓はどこかに入れなければいけない。さもないと整頓しない。ではどこに入れればよいだろうか？ 結論。整頓はそれ用のプルリクエストに入れる。整頓はプルリクエストごとにできるだけ少数にする。

もう少し詳しくトレードオフを見ていこう。整頓を学んでいる人たちには、同じような傾向が見られる。最初はただ変更するだけで、何も区別していない大量の変更から始める（図16-1）。

図16-1　何も区別していない大量の変更

ここで、ifステートメントを修正している途中で名前が間違っていることに気づき、それを直してからifステートメントに戻る。変更は変更だ。

整頓を学んだあとは、まるで顕微鏡のピントが合ったときのようになる。変更のいくつかはプログラムの振る舞いと属性に関するもので、プログラムを動かすとわかるものだ。だが、変更のなかには、プログラムの構造を変更しているものもある。このような変更はコードを見ないとわからない。 ...