コードをDRY化したのにかえって扱いにくくなった？重複リファクタリングの落とし穴と「3回目の法則」

DRY原則の価値と、その落とし穴

「Don't Repeat Yourself（同じことを繰り返すな）」、通称DRY原則は、ソフトウェア開発者にとって必読の書籍から生まれた、最も価値のある考え方のひとつです。重複したコードをリファクタリングで取り除くことができれば、より汎用的で、より安定したコードを生み出せます。

しかし、いざコードをDRYにし始めると、いくつかの問題に直面することになります。エッジケース（境界条件）をうまく処理できないコード、一般化されすぎて読みにくいコード、そしてどこにあるのか分かりにくいコード——。DRY化のためのリファクタリングが常にうまくいくとは限らないなら、いつリファクタリングすべきかをどう判断すればよいのでしょうか？

「本質的な重複」と「偶然の重複」を見分ける

過度にDRY化されたコードは、「どの種類の重複をリファクタリングすべきか」という誤解から生まれます。ここで必要なのは、本質的（essential）な重複と偶然（accidental）の重複を見分ける力です。

本質的な重複とは、あなたが取り組んでいる問題領域そのものを解決するために存在するコードの重複です。この種の重複は、すぐにでも排除すべきものです。

一方、偶然の重複とは、目の前の問題とは無関係な、いわば「偶然による一致」です。偶然の重複をあまりに攻撃的に除去すると、新しいケースが追加されるたびにリファクタリングをやり直さなければならない、脆いコードになってしまいます。

判断に迷ったら「3回目の法則」を使う

では、どうやって両者を見分ければいいのでしょうか？経験を積めば上達するかもしれませんが、何十年もプログラミングを続けてきた私でも、半分も正確に判断できていません。幸い、非常に役立つシンプルなルールがあります。それが「Three Strikes and You Refactor（3回繰り返したらリファクタリングせよ）」です。

1回目：ただ書く。

2回目：似た処理が必要になったら、重複に顔をしかめつつも、とにかく重複したまま書く。

3回目：さらに似た処理が必要になったら、ようやくリファクタリングする。

なぜこのルールが有効なのか、お分かりでしょうか？3回目の時点で、パターンが見え始めるはずです。どの重複コードが問題解決に不可欠で、どのコードが単に偶然同じに見えるだけなのか、おおよそ見当がつくようになります。そうすれば、解決しようとしている問題のすべてのケースにわたって根本的に同じであるコードだけを汎用化（DRY化）できるのです。

過去の失敗を振り返ってみる

少し立ち止まって、最後にリファクタリングで苦労した場面を思い出してみてください。2箇所の間で重複している部分をDRY化しようとしたのに、3箇所目のコードが少しだけ違っていて困った——そんな経験はありませんか？それは「偶然の重複」まで早まって統合してしまった典型例かもしれません。

次にコードを重複させなければならないと感じたら、あえて3箇所目が現れるまでリファクタリングを待ってみてください。（本当に難しく、気持ち悪く感じるでしょうが、目をつぶって試してみましょう）。そして、実際にDRY化しながら自問してみてください。2箇所目を書いた直後にリファクタリングしていた場合と比べて、設計の切り口は変わっていませんか？