PaaSDockerLinuxを触ってみる。.NET開発基盤部会」によって運営されています。用例ポジティブなコンテキスト。ネガティブなコンテキスト。定義を忘れるためメモ。前者(コードを対象としているという主張)が正しい。「ソフトウェア開発全体において情報を重複させない」という原則。Once”(OAOO)原則と呼ばれるものである。クラス(コード)に対して適用される。†2つのコンテキストがある。業務系などライフサイクルが長いケースでは前者が重視されていると思う。Web、ゲームなどライフサイクルが短いケースでは後者が重視されていると思う。↑ポジティブなコンテキスト。標準化・共通化などは半ば常識的に行われる。密結合なDryの状態で開発されていたら、大規模化して長期の維持・保守が必要になった場合に、対応できなくなる。標準化・共通化のレイヤは、追加されたUIコントロールなどで、かなり分厚くなる。↑ネガティブなコンテキスト。観測範囲で、Web、ゲームやフリーランス界隈でも、Dryが尊ばれている様に見える。下記のように、「Dryで書いたものが負債になっていく。」という発言もあり、ライフサイクルが短く、スクラップ・アンド・ビルドなプロジェクトでは、デメリットを理解する必要がある。モジュール強度が強く、結合度が弱くなる境界で分割されていない。デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。フレームワークの生のAPIを触りたい。低品質な≒オレオレ的なレイヤを構築したくない(&触りたくない)。なんとなく、時間を掛けて適切な設計が出来無い案件でDryが問題になっているように見える。モジュールとしてまとめられたときに困るのは、自由度が制限されること。モジュール化するべきか、しないべきか、については慎重に考えたい。基本スタックしないとダメそう。凝集度・結合度に問題がある下位スタックだと逆効果。いうこともあって、デメリットについての言及も増える。技術的な分解点とドメイン理解の双方がないと正しく行うことはできない@mizchiさんの「DRY」に対する言及コレクション。Qiitahttps://qiita.com/yatmsu/items/b4a84c4ae78fd67a364cDRYは素晴らしい考えですが、やり過ぎると密結合を生んでしまう。密結合が進むと修正時に影響範囲が増えてしまうんですね。ソフトウェア開発原則は他にも多数存在するわけで、それぞれコンテキストによって用法・容量を正しく守って使いましょうということでした。コードの重複と密結合の間https://www.infoq.com/jp/news/2012/05/DRY-code-duplication-couplingDRYは重複とそれに伴うメンテナンスの問題を軽減するものだが、誤用すると密結合を生み、可読性を損うおそれがある。教訓:ソフトウェア開発原則は、ほかの原則やパターン、プラクティスを考慮して適用しなくてはならない。POSTDhttps://postd.cc/on-dry-and-the-cost-of-wrongful-abstractions/抽象化のコストがコードを重複させるコストを上回らない限り、必ず抽象化する。