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

20章絡まりを解きほぐす

　

あなたは、あるコードの振る舞いを変更している。ここを整頓すれば変更しやすそうだ。整頓する。そして次のテストケースを書く。ここでも振る舞いを変更する必要がありそうだ。また整頓する。1時間後あなたはこうなっている。

• どんな振る舞いの変更が必要かすべて理解している。
• どんな整頓が振る舞いの変更を簡単にするかすべて理解している。
• 整頓と変更がこんがらがってぐちゃぐちゃになっている。

選択肢は少なくとも3つあるが、どれも魅力的とは言えない。

• そのまま進める。レビュアーには不親切だしエラーも起こりがちだが、手っ取り早い。
• 整頓と変更を別々のプルリクエストにする、もしくは、連続したプルリクエストにする、もしくは、連続したコミットからなる単一のプルリクエストにする。親切だが、手間がかかる。
• 進行中の作業を破棄して初めからやり直し、先に整頓する。さらに手間がかかるものの、連なったコミットには一貫性が生まれる。

サンクコストの誤謬がこの選択を難しくする。新しいテストがいくつかある。パスしている。なぜそれを捨てたいと思うのか。

それは常に、あなたは単にコンピューターに命令しているだけでなく、コンピューターに対するあなたの意図を他の人に伝えようとしているからだ。コンピューターに意図を伝えるための最短のパスは、関心を注ぐべき最終ゴールではないのだ。

本書もここまでくれば、私が最後の選択肢を選んで実験するよう促しても、もはや驚く人はいないだろう。再実装するほど新しい発見の可能性は高まり、同じような振る舞いの変更からも多くの価値を引き出せるようになる。

毛糸の玉を解きほぐすのは、絡まりがあることに気づくことから始まる。解きほぐす必要性に気づくのが早いほど、作業は小さくなる（そして、戦略間の意思決定の重要性は低くなる）。初めて意図的に整頓を始めるときは、先にするにしてもあとにするにしても、「変更を入れながらうまく進めている」から「ヤバい、何をしてしまったんだ？」に気づかないうちに移行してしまっているかもしれない。心配無用だ。そのうちに整頓と変更の優先順位付けも上達するはずだ。 ...