カテゴリ: 原則
種類: ソフトウェア開発の原則
起源: ソフトウェア工学、1990年代 / The Pragmatic Programmer、1999年
別名: DRY、Don’t Repeat Yourself、Single Source of Truth
種類: ソフトウェア開発の原則
起源: ソフトウェア工学、1990年代 / The Pragmatic Programmer、1999年
別名: DRY、Don’t Repeat Yourself、Single Source of Truth
クイックアンサー — DRYの原則（Don’t Repeat
Yourself）は、あらゆる知識はシステム内で単一の明確な表現を持たなければならないという原則です。1999年にアンディ・ハントとデイブ・トーマスの『The
Pragmatic
Programmer』で初めて明確に述べられたDRYは、ソフトウェア開発において最も影響力のある原則の一つとなりました。この原則は、コードだけでなく、ドキュメント、データベーススキーマ、テスト、その他のシステム成果物にも及びます。情報が重複している場合、変更には複数の更新が必要になり、不整合やバグのリスクが高まります。
DRYの原則とは
DRYの原則は、コード、ドキュメント、その他のシステム成果物における重複排除を提唱するソフトウェア開発哲学です。そのコアアイデアは見かけ以上にシンプルです。ビジネスルール、計算、データ構造、ユーザーインターフェース要素など、あらゆる知識は正確に一つの場所に存在すべきなのです。同じ情報が複数回現れると、開発者はすべてのインスタンスを更新することを覚えておく必要があり、継続的な保守負担とエラーの機会を生み出します。「重複は、よく設計されたシステムの主要な敵である。」— アンディ・ハント、デイブ・トーマス『The Pragmatic Programmer』この原則は、ソフトウェア開発のベストプラクティスの多くを確立した影響力のある書籍『The Pragmatic Programmer』（1999年）を通じて広く認識されるようになりました。しかし、その根底にあるアイデアは本書以前から存在していました。ロジックの複製が保守の悪夢を生むことは、プログラマーによって長年認識されていたのです。ハントとトーマスが行ったのは、この原則を明確に述べ、記憶に残る名前を与えたことでした。 DRYは多くの形態の重複に適用されます。コードの重複は、同じロジックが複数の場所に現れる場合に発生します。ドキュメントの重複は、同じ情報が複数のドキュメントで説明される場合に発生します。データの重複は、同じデータが複数の場所に保存される場合に発生します。スキーマの重複は、データベース構造が互いに鏡像関係になる場合に生じます。この原則は、開発者に各知識の単一の信頼できる情報源を特定し、この情報源を参照するシステムを構築するよう求めています。
DRYの原則を3つの深さで理解する
- ビギナー: コードをコピーアンドペーストする際、立ち止まって自問してください。「これを再利用可能な関数や変数に抽出できますか？」小さな重複でさえ、時間とともに複合的に増大します。
- プラクティショナー: 関数、クラス、モジュール、サービスなど、複数のレベルでDRYを適用してください。継承、コンポジション、設定管理などのテクニックを使って、知識を一元化してください。
- アドバンスド: 過度に積極的なDRYが不適切な結合を生む可能性があることを認識してください。時には、間違った抽象化よりも重複の方が望ましいことがあります。DRYとYAGNI、KISSの原則のバランスを取ってください。
起源
DRYの原則は、アンディ・ハントとデイブ・トーマスによる『The Pragmatic Programmer: From Journeyman to Master』（1999年）で正式に紹介されました。ソフトウェア開発文献の礎となった本書は、DRYを保守可能なソフトウェアを構築するためのコア原則として説明しました。ハントとトーマスは、重複が理解、変更、拡張が困難なシステムにつながると論じました。 この原則は、ソフトウェア工学の以前のアイデアの上に構築されました。データベース設計における「single source of truth」の概念はDRY以前から存在していましたし、定数を一つの場所で定義し、コード全体で参照する実践も同様です。DRYに影響力を与えたのは、コードだけでなく、ドキュメント、プロセス、組織構造を含む、あらゆる形態の知識の重複に幅広く適用されたことでした。 DRYの普及のタイミングは重要でした。1990年代後半には大規模ソフトウェアシステムの成長が見られ、開発者は複製されたコードベースの保守課題にますます直面していました。DRYは、システムのライフサイクル全体にわたって配当を生む設計決定を行うための明確なヒューリスティックを提供しました。今日、DRYはコンピュータサイエンスプログラムで教えられ、世界中のプロフェッショナル開発チームによって遵守される基盤的な原則であり続けています。要点
応用場面
コードリファクタリング
複製されたロジックを再利用可能な関数、クラス、モジュールに抽出してください。継承やコンポジションを使って、実装を複製することなく振る舞いを共有してください。
設定管理
設定値を集中化されたファイルや環境変数に保存してください。環境間で変更される可能性のある値をハードコーディングしないでください。
データベース設計
冗長なデータ保存を排除するためにデータベーススキーマを正規化してください。テーブル間でデータを複製するのではなく、外部キーと結合を使用してください。
ドキュメント
概念を一度説明し、その説明を全体で参照するドキュメントを書いてください。同じ情報を複数の場所で繰り返し述べることを避けてください。
事例
Ruby on Railsフレームワークは、DRYの原則を象徴的に体現しています。Railsは「設定より規約」という概念を導入しており、一般的なパターンが一度定義され、アプリケーション全体に自動的に適用されます。例えば、Railsのモデル定義はデータベースアクセスメソッドを自動的に生成します。同じロジックが複数の場所に複製されることはありません。Rails開発者がモデルとデータベースの相互作用方法を変更する必要がある場合、一か所に変更を加えるだけで、アプリケーション全体に反映されます。このアプローチにより、Railsアプリケーションは保守と修正が非常に容易になり、開発者はDRYをそれほど重視しないフレームワークと比較して、複製されたコードが大幅に少ないと報告しています。境界と失敗モード
DRYの原則は本質的ですが、重要な制限があります。第一に、過度に熱心なDRYは不適切な抽象化を生む可能性があります。無関係な概念を共有コードに強制すると、タイトな結合が生まれ、元のコードと「リファクタリングされた」バージョンの両方の保守が困難になります。 第二に、時期尚早な抽象化は危険です。DRYは、証明された重複のリファクタリングをガイドすべきであり、投機的な一般化を促すものではありません。いつか再利用されるかもしれないコードのための抽象化を作成すると、複雑で理解しにくいシステムにつながることが多いです。 第三に、一部の重複は許容可能であり、必要不可欠なことさえあります。類似しているように見えるコードでも、存在する理由が異なる場合があり、それらを一緒に強制すると誤った統一が生まれます。テストコードは、本番コードから構造を複製することがありますが、これには正当な理由があります。テストは独立して保守可能でなければならないのです。よくある誤解
DRYは決してコードをコピーしないことを意味する
DRYは決してコードをコピーしないことを意味する
DRYは、知識の重複を避けることであり、リテラルなコードではありません。構文の繰り返しは、根底にある知識が単一ソースのままの場合、最も明確なソリューションになることがあります。
DRYは常に保守性を向上させる
DRYは常に保守性を向上させる
不正確な抽象化は保守をより困難にする可能性があります。重複を抽出する前に、抽象化が共有概念を正確に表現していることを確認してください。
DRYはコードにのみ適用される
DRYはコードにのみ適用される
この原則は、ドキュメント、データベーススキーマ、API設計、組織プロセスにも及びます。繰り返される知識は、すべてDRY処理の候補です。
関連コンセプト
KISSの原則
DRYはコードを単純化し、理解しやすくすることが多いです。KISSは、単純さが重複の排除方法をガイドすべきであると強調することでDRYを補完します。
YAGNIの原則
必要になるまで再利用可能なコンポーネントを構築しないでください。YAGNIは、DRYの精神に反する時期尚早な抽象化を防ぎます。
Single Source of Truth
データが一つの場所に保存されるべきという関連するデータベース概念です。DRYは、このアイデアをシステム内のすべての知識に適用したものです。
コードリファクタリング
多くの場合DRYを適用することでコード構造を改善する実践です。リファクタリングは、DRYを実装する運用活動です。
オッカムの剃刀
両方の原則は単純さを支持します。DRYは重複を排除し、オッカムの剃刀は不要な前提を排除します。