DRY のようなデザイン原則 (design principles) は、乗り越えなければならない問題や挑戦が渦巻くソフトウェア開発において、成功に導く一条の光を投じてくれるものです。それらは、クリーン (clean)、明確 (clear)、維持可能 (maintainable) な解決策へとあなたを導くために、ほんの小さな声で囁きかけてくれます。それを無視するのも勿論あなたの自由ですが、それがあなたを「何か落ち着かない気分」にさせるのも確かでしょう。

あなたが取り組んでいるコードの中にみんなが「手を出したくない」と思うようなパートがあるのだとしたら、それはそのパートを担当した開発者（あなたかもしれないし前任者かもしれません）がデザイン原則の「囁き声」に耳を貸さなかったからでしょう。

「耳に優しいこと」ばかりを言うつもりはありません。こういった原則を取り入れようと決断しても、最初のうちは上手くいかないことが多いはずです。物事を正しい方法でこなせるようになるには少し時間が必要です。しかし長期的に見ればそれは必ず報われます。

Gang of Four による著書「オブジェクト指向における再利用のためのデザインパターン: Design Patterns - Elements of Reusable Object-Oriented Software)」において、一般的問題を解決するための２大原則、として挙げられているのが以下になります:

特に１つ目の原則は肝に銘じておくべきです。メール送信プログラムの例でいえば、メール送信機能を実装するクラスの中で、同時に送信対象ユーザーのデータを読み込む機能まで一緒に実装しないようにする、ということです。この機能を別クラスに分離して提供するようにすることで、メール送信機能本体では、このデータがどこから来ているのか、ということに一切関知する必要がなくなるばかりか、将来的にユーザーデータ取得元のフォーマットを変更したり、ファイルからではなくデータベースや外部のマイクロサービスから取得するように変更したとしても、メール送信機能本体クラスには一切影響を及ぼしません。