「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
定義を忘れるためメモ。
対象 †
恐らく前者（コードを対象としているという主張）が正しい。
コードを対象としているという主張 †
単に「コードを重複させない」という原則ではなく、
- DBスキーマ、
- テスト、
- ビルドシステム、
- ドキュメント
なども対象になっており、
「ソフトウェア開発全体において情報を重複させない」
という原則。
コードを対象としていないという主張 †
OAOO(Once and Only Once) †
転じて、プログラムコード中で同じ(ような)動作をするコードを何度も書かずに、
一度書いたものを再利用するようにすべきとする意味で用いられることもあるが、
こちらは本来は“Once and Only Once”(OAOO)原則と呼ばれるものである。
クラス、オブジェクトに対する適用 †
- DRY はオブジェクト・インスタンス（データ）に対して適用されるのに対して、
- OAOO はクラス（コード）に対して適用される。
用例 †
２つのコンテキストがある。
- 業務系などライフサイクルが長いケースでは前者が重視されていると思う。
- Web系などライフサイクルが短いケースでは後者が重視されていると思う。
Dryに関してポジティブなコンテキスト。 †
- 大規模なSI案件では、標準化・共通化などは半ば常識的に行われる。
密結合なDryの状態で開発されていたら、大規模化して
長期の維持・保守が必要になった場合に、対応できなくなる。
- Open棟梁導入案件でも、案件毎に、更に追加のレイヤが追加されるので、
標準化・共通化のレイヤは、追加されたUIコントロールなどで、かなり分厚くなる。
Dryに関してネガティブなコンテキスト。 †
- 観測範囲で、Webやフリーランス界隈でも、Dryが尊ばれている様に見える。
- しかし、下記のように、「Dryで書いたものが負債になっていく。」という発言もあり、
ライフサイクルが短く、スクラップ・アンド・ビルドなプロジェクトでは、デメリットを理解する必要がある。
- ≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。
- ≒ デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。
- フレームワークの生のAPIを触りたい。
- 低品質な≒オレオレ的なレイヤを構築したくない（＆触りたくない）。
- 項目位相おじさんのhierarchyの上層にframeworkに詳しい人材ってのが居る気がするが、
コレには以下のような背景がアルっぽい。外部要因次第で判断は変えたほうが良い。
- frameworkの生のapiに触りたいのでdryは嫌。
- 集めたengineerが密結合なクソコードを量産するから素描の方がマシ。
参考 †
密結合のデメリットについての言及 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
