コードを早まってDRYにしない

私たちの多くは、 「同じことを繰り返さないで」 またはDRY。ちょっと立ち止まって考えてみましょう。 重複は本当に冗長なのか、それとも時間の経過とともに機能が独立して進化する必要があるのか? DRY 原則を厳格に適用しすぎると、抽象化が早まってしまい、将来の変更が必要以上に複雑になってしまいます。

コードが本当に冗長なのか、それとも表面的に似ているだけなのかを慎重に検討してください。 関数やクラスは同じに見えても、時間の経過とともに変化するさまざまなコンテキストやビジネス要件に対応する場合もあります。コードを短くすることだけでなく、関数の目的が時間の経過とともにどのように変化するかを検討してください。 抽象化を設計するときは、長期的には別々に進化する可能性のある動作を時期尚早に結合しないでください。

抽象化を導入するとコードに悪影響が出るのはどのような場合でしょうか? 次のコードを考えてみましょう。

右側のアプローチはDRY原則に違反しているように思われる。 値エラー チェックは 偶然にも 同じです。ただし、タスクと支払いは、異なるロジックを持つ異なる概念を表します。 後で支払い日に新しい検証が必要になった場合は、右側のコードに簡単に追加できますが、左側のコードに追加すると、はるかに侵入的になります。

疑わしい場合は、時間の経過とともに結合を正当化する十分な共通パターンが出現するまで、行動を分離したままにしておく小規模な場合、重複を管理することは、未熟な抽象化の複雑さを解決するよりも簡単な場合があります。 開発の初期段階では、多少の重複を許容し、抽象化を待ちます。

将来の要件は予測できないことが多い。 「それは必要ない」 または YAGNI 原則。重複は問題にならないことが判明するか、時間の経過とともに、十分に検討された抽象化の必要性が明確に示されることになります。