-
Notifications
You must be signed in to change notification settings - Fork 0
DNET_DRY
定義を忘れるためメモ。
様々な参考情報を参考にすると、恐らく、
前者(コードを対象としているという主張)が正しい。
単に「コードを重複させない」という原則ではなく、
- DBスキーマ、
- テスト、
- ビルドシステム、
- ドキュメント
なども対象になっており、
「ソフトウェア開発全体において情報を重複させない」
という原則。
転じて、プログラムコード中で同じ(ような)動作をするコードを何度も書かずに、
一度書いたものを再利用するようにすべきとする意味で用いられることもあるが、
こちらは本来は OAOO(Once And Only Once) 原則と呼ばれるものである。
- DRY はオブジェクト・インスタンス(データ)に対して適用されるのに対して、
- OAOO はクラス(コード)に対して適用される。
2つのコンテキストがある。
- 業務系などライフサイクルが長いケースでは前者が重視されていると思う。
- Web、ゲームなどライフサイクルが短いケースでは後者が重視されていると思う。
共通化などを行ったDry。
-
大規模なSI案件では、
チーム開発でも疎結合なDryの状態を維持するため、
標準化・共通化などは半ば常識的に行われる。密結合なDryの状態で開発されていたら、大規模化して
長期の維持・保守が必要になった場合に、対応できなくなる。 -
Open棟梁導入案件でも、案件毎に、更に追加のレイヤが追加されるので、
標準化・共通化のレイヤは、追加されたUIコントロールなどで、かなり分厚くなる。
(車輪の再開発はしない的な)素描Dry。
-
観測範囲で、Web、ゲームやフリーランス界隈でも、Dryが尊ばれている様に見える。
-
しかし、下記のように、「Dryで書いたものが負債になっていく。」という発言もあり、
ライフサイクルが短く、スクラップ・アンド・ビルドなプロジェクトでは、デメリットを理解する必要がある。-
≒ モジュール強度が強く、結合度が弱くなる境界で分割されていない。
-
≒ デファクトなフレームワークの生のAPIを触りたい為、レイヤ分割を避けている。
- フレームワークの生のAPIを触りたい。
- 低品質な≒オレオレ的なレイヤを構築したくない(&触りたくない)。
-
※ なんとなく、時間を掛けて適切な設計が出来無い案件でDryが問題になっているように見える。
ありそう。
-
モジュールとしてまとめられたときに困るのは、
凝集度が低く、結合度が高くて、自由度が制限されること。 -
モジュール化するべきか、しないべきか、については慎重に考えたい。
基本スタックしないとダメそう(素描DryはDryじゃないダロ的な)。
- しかし、凝集度・結合度に問題がある下位スタックだと逆効果。
- こういうこともあって、デメリットについての言及も増える。
-
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/ -
プリンシプルオブプログラミングを読んだ • nemupm
https://nemupm.com/blog/2018/02/12/principles-of-programming/
-
@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/抽象化のコストがコードを重複させるコストを上回らない限り、必ず抽象化する。
正誤
- 「こちらは本来は“OAOO(Once And Only Once)原則と呼ばれるものである。」の 閉じられていない開き二重引用符(“)は、対応する閉じ引用符が無く誤記と判断して除去した。
移行メモ
- 元 Wiki では見出しそのものが他ページへのリンクになっていた箇所 (「OAOO原則」)は、GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
- PukiWiki のページ内アンカ(
#xxxxxxxx)は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替えた。- Open 棟梁 Wiki(opentouryo.osscons.jp)へのリンクは、 当該サイトが未移行のため URL のままとした。
Tags: 移行, DRY, Don't repeat yourself, OAOO, 原則, 共通化, 凝集度, 結合度
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。