「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>FrontPage]] *目次 [#afeb9d1d] #contents *概要 [#ec85b2a4] 定義を忘れるためメモ。 *対象 [#m1f0cf4b] 恐らく[[前者(コードを対象としているという主張)>#i6c06441]]が正しい。 **コードを対象としているという主張 [#i6c06441] 単に「コードを重複させない」という原則ではなく、 -DBスキーマ、 -テスト、 -ビルドシステム、 -ドキュメント なども対象になっており、 「ソフトウェア開発全体において情報を重複させない」 という原則。 **コードを対象としていないという主張 [#n6367ffb] ***OAOO(Once and Only Once) [#q6d9bd61] 転じて、プログラムコード中で同じ(ような)動作をするコードを何度も書かずに、~ 一度書いたものを再利用するようにすべきとする意味で用いられることもあるが、~ こちらは本来は“Once and Only Once”(OAOO)原則と呼ばれるものである。 ***クラス、オブジェクトに対する適用 [#we38c88a] -DRY はオブジェクト・インスタンス(データ)に対して適用されるのに対して、 -OAOO はクラス(コード)に対して適用される。 *用例 [#w3e98c70] 2つのコンテキストがある。 -業務系などライフサイクルが長いケースでは前者が重視されていると思う。 -Web系などライフサイクルが短いケースでは後者が重視されていると思う。 **Dryに関してポジティブなコンテキスト。 [#d6b5475e] -大規模なSI案件では、標準化・共通化などは半ば常識的に行われる。 >密結合なDryの状態で開発されていたら、大規模化して~ 長期の維持・保守が必要になった場合に、対応できなくなる。 -[[Open棟梁>http://opentouryo.osscons.jp/]]導入案件でも、案件毎に、更に追加のレイヤが追加されるので、~ 標準化・共通化のレイヤは、追加されたUIコントロールなどで、かなり分厚くなる。 **Dryに関してネガティブなコンテキスト。 [#y14f8197] -観測範囲で、Webやフリーランス界隈でも、Dryが尊ばれている様に見える。 -しかし、下記のように、「Dryで書いたものが負債になっていく。」という発言もあり、~ ライフサイクルが短く、スクラップ・アンド・ビルドなプロジェクトでは、[[デメリット>#odf5da81]]を理解する必要がある。 --≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。 --≒ デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。~ ---フレームワークの生のAPIを触りたい。 ---低品質な≒オレオレ的なレイヤを構築したくない(&触りたくない)。 -項目位相おじさんのhierarchyの上層にframeworkに詳しい人材ってのが居る気がするが、~ コレには以下のような背景がアルっぽい。外部要因次第で判断は変えたほうが良い。 --frameworkの生のapiに触りたいのでdryは嫌。 --集めたengineerが密結合なクソコードを量産するから素描の方がマシ。 *参考 [#had64951] -Don't repeat yourself - Wikipedia~ https://ja.wikipedia.org/wiki/Don%27t_repeat_yourself -DRY原則(Don't Repeat Yourself)とは - IT用語辞典~ http://e-words.jp/w/DRY%E5%8E%9F%E5%89%87.html -DRY原則 | プログラマが知るべき97のこと~ https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/DRY%E5%8E%9F%E5%89%87/ **密結合のデメリットについての言及 [#odf5da81] -@mizchiさんのツイート: --https://twitter.com/mizchi/status/959297746908856320 >DRY、よかれと思って書かれたものが負債になってることのほうが多くないですか --https://twitter.com/mizchi/status/1078243362640093185 >本当に共通化できるモジュールを発見するのは、~ 技術的な分解点とドメイン理解の双方がないと正しく行うことはできない --@mizchiさんの「DRY」に対する言及コレクション。~ https://twitter.com/search?l=&q=Dry%20from%3Amizchi&src=typd -あなたはDRY原則を誤認している? - Qiita~ https://qiita.com/yatmsu/items/b4a84c4ae78fd67a364c --DRYは素晴らしい考えですが、やり過ぎると密結合を生んでしまう。密結合が進むと修正時に影響範囲が増えてしまうんですね。 --ソフトウェア開発原則は他にも多数存在するわけで、それぞれコンテキストによって用法・容量を正しく守って使いましょうということでした。 -DRY原則の利用: コードの重複と密結合の間~ https://www.infoq.com/jp/news/2012/05/DRY-code-duplication-coupling --DRYは重複とそれに伴うメンテナンスの問題を軽減するものだが、誤用すると密結合を生み、可読性を損うおそれがある。 --教訓:ソフトウェア開発原則は、ほかの原則やパターン、プラクティスを考慮して適用しなくてはならない。 -DRYと不当な抽象化によるコストについて | POSTD~ https://postd.cc/on-dry-and-the-cost-of-wrongful-abstractions/ >抽象化のコストがコードを重複させるコストを上回らない限り、必ず抽象化する。