ソフトウェア開発者は、パターンを認識することが得意です。 もしかしたら、それがこの職業に引き寄せられた先天的なスキルなのかもしれません。 あるいは、ソフトウェアを書くというプロセスがこのスキルを発達させるのかもしれません。 いずれにせよ、「同じことを繰り返さない」（DRY）は、このスキルの自然なアプリケーションです。
しかしながら、繰り返しそれ自体は、この原則が言うような敵ではありません。
- Don’t Repeat Yourself
- Sometimes Repeat Yourself
- Questions to Ask
- これは重複している単一の知識なのか、たまたま似ているだけのインフラなのか。 それはおそらく、別のクラスの定義を避ける十分な理由にはなりません。 How many times have this thing been repeated?
- 今、重複を減らすと、将来、個々のケースをカスタマイズするのが難しくなるでしょうか。
- If I reduce this duplication, what is the ratio between the size of the abstraction and the number of parameters it will take.
- 結論
Don’t Repeat Yourself
「繰り返すな」と同じくらい直観的ですが、The Pragmatic Programmer はこのように要約します：
すべての知識の断片はシステム内で単一の、あいまいではない、信頼できる表現を持っていなければならない。
繰り返しを減らす、または排除することの利点は想像に難くありません。
- 重複が少ないということは、保守するコードが少ないということです。 そして、最良のコードがまったくないものであるならば、これは良いことのように聞こえます。
- 単一の真実のソースは、物事が同期しなくなる可能性を排除します。 あるビジネス ルールが変更されましたか。 3647>
- コードは再利用可能です。 3つのものによって共有されているプロセスがあり、4つ目を追加しようとしていますか?
Sometimes Repeat Yourself
見かけ上の重複を減らすことに熱中しすぎると、解決するよりも多くの問題を引き起こす可能性があります。 私が「見かけ上の重複」と言ったのは、似ているように見えるものが実際には関連していないことがあるからです。 たとえば、同一のプロパティと型を持つ 2 つのデータ構造は、構造的には同じですが、意味的には同じではありません。
重複するコードを減らすための一般的な戦略は、共通部分を因子抽出して、抽象化の背後に隠すことです。 しかし、これの望ましくない副作用は、抽象化を使用するものを結合してしまうことです。 抽象化を変更すると、その消費者すべてに影響が及びます。 また、同様に、抽象化はただ 1 人の消費者の要件に合うように曲げられる必要があるかもしれません。
この結合の増加は、柔軟性の低下も伴います。 たとえば、3 か所で使用されるプロセスがあるとします。 それは 3 つの場所すべてでほぼ同じですが、ほんの少し重要な違いがあります。 そこで、そのプロセスを1つのモジュールとして実装し、いくつかのパラメータを取ることで違いをカバーします。
これらのユースケースのうちの 1 つだけのためにプロセスを調整することは、今では不可能です：1 つを変更すると、3 つすべてに影響します。 もちろん、ユースケースが分岐するにつれて、より多くのパラメーター (または特殊なケース!) を追加することは可能です。 しかし、ユースケースを分けるインフラからプロセスの重要な部分を区別することは、すぐに不可能になるでしょう。
Questions to Ask
既存のコードをリファクタリングするとき、または重複する可能性のある新しいコードを書くとき、私は自分自身に問いかけます：
これは重複している単一の知識なのか、たまたま似ているだけのインフラなのか。 それはおそらく、別のクラスの定義を避ける十分な理由にはなりません。
How many times have this thing been repeated?
Really redundant thing appears at least three times, I would be very skeptical of any repetition-reduction that increases complexity.
Until a redundant thing appears at least three times, I would be very skeptical for the repetition-reduction that increases complexity.
今、重複を減らすと、将来、個々のケースをカスタマイズするのが難しくなるでしょうか。
コピー アンド ペーストのコードの束を、より合理的で再利用可能なものにリファクタリングすることに満足するものがあります。 しかし、どんな変更も特殊なケースを導入するようにコードをきつくロックすることは、良いトレードオフではありません。
If I reduce this duplication, what is the ratio between the size of the abstraction and the number of parameters it will take.
Libraries and frameworks are great because they provide reusable code with relatively few parameters for customization.Librasses and frameworks are great. しかし、ダイアログ ボックスを表示するためのアプリケーション固有の関数が成長し、今では 20 のパラメーターを受け取るようになったと想像してください。
結論
多くのソフトウェア開発原則と同様に、「同じことを繰り返さない」はマントラというよりもガイドラインです。