データ管理 の変更点

• 追加された行はこの色です。
• 削除された行はこの色です。
• データ管理 へ行く。
• データ管理 の差分を削除

[[FrontPage]]


「データはクラウドにひとつだけ」
DRY は、Andy Hunt と Dave Thomas の著書 The Pragmatic Programmer (邦題:達人プログラマー) において中心となる原則である。 彼らはこの原則を、データベーススキーマ、テスト計画、ビルドシステムや、ドキュメンテーションにいたるまで非常に幅広く適用している [1]。
DRY 原則がうまく適用されたとき、システムに対するいかなる要素の変更も、論理的に関連のない他の要素の変更にはつながらない。さらに、論理的に関連した要素は予測できる形で統一的に変更され、したがってそれらの変更は同期が取れたものとなる。
DRY 原則が有用でない場合
冗長化やミラーリング。
小規模のコンテキストでは、DRY に基づき設計する労力は、二つの別々のデータのコピーを維持管理する労力よりはるかに大きくなる。
DRY 原則を厳守するような標準の強要は、wikiなどのコミュニティの参加に高い価値があるようなコンテキストでは、コミュニティの参加を阻害してしまう。
構成管理とバージョン管理は、DRY 原則を逸脱することなく同じコードのコピーを許容する。たとえば、良い例として開発用の環境、テスト用の環境、製品版コード用の環境を構築し、進行中の開発とテストが製品のコードに影響を与えないようにする方法がある。
人間が読むことができる文書(コードのコメントから印刷されたマニュアルまで)は、通常はコードの内部まで読んで理解する能力や時間がない人のための推敲、説明を加えてコードの内部にあるものを再度記述している。しかし、DRY では、人間が読むことができるドキュメントはフォーマットの変更を除けば何の価値もなく、すなわち記述されるのではなく生成されるべきとしている。
ソースコードの生成 - 重複の禁止はソースコード生成には役立つが、それは出力結果に対してではなく、重複した情報が人間や他のコードによって変更されない場合のみである。
単体テスト - ソースコードとの矛盾を見つけ出すのが目的であり[2]、ソースコードから自動生成すべきではない。ただし、ソースコメントやドキュメントから自動生成する事はありうる。[3]
Abel Avramは、DRYを過度に追求する事で疎結合の原則が破られる例を示し、DRYはあくまで他の原則との兼ね合いの元で守られるべきだと述べている。[2]