DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場

「過剰なDRYが技術的負債を生む」みたいな内容の記事を書きたいが、うまく言語化できない。「過剰な食事制限が健康を損なう」程度の内容に成り下がりそうだけど、そんなんじゃないんだよ… @methane 実装におけるDRYみたいなものを考えていて、そうすると前者のDRYというのがどこに位置づけられるかはわからないんですが、とにかく暗黙知みたいなものを過剰に増やすDRYは良くないよね、というような話なんです という@moriyoshitさんのツイート（1, 2）を見かけたので、僕の考え方をコメント。moriyoshitさんの考えたい問題とは、ずれてるかも。 DRY化の功罪とは何か？ 僕の理解で言うと、共通するコード片をDRY化することには以下の変化をもたらす。 循環的複雑度は変化しない コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する*1 関数内の複

[kazuhooku]

ぱっと書いた

[toromoti]

DRYとはなにかを知らない人たちの中でDRYしても意味ない。負債はもとからあるんだよ。DRYすら知らない職場っていうのが最大の負債だわちくしょう！

[enk_enk]

もっともだしシンプルで悪くない

[kyab]

DRYでぱっと見全体はきれいになるけどトラブったらすべてのレイヤを縦断的に見ないといけないから解析する観点からはコールグラフの複雑化いやんってのは思う。

[sweet-programming]

“モジュール間の複雑性上昇を抑えるため、DRY化はできるだけ局所的に行う”そういう観点でDRY化をしないでいたら、怒られて、リファクタリングのためにスケジュールを遅らせて怒られたアカウントがこちらです。

[k1take]

「 モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する 」そんな人のためにドメイン駆動設計ですよ。と言ってみる。

[shin1x1]

"関数内の複雑度の低下によるメリットが、コールグラフの複雑度の上昇によるデメリットを上回る場合のみ、DRY化を行う"

[ledsun]

複数ツール作っていて共通関数をモジュールに移動する。モジュールが増え複数モジュールの共通関数を共通モジュールに移動する。モジュールの取り込み順序の管理が必要になる。みたいな話かな？

[nilab]

DRY(don't repeat yourself)するかしないか、その判断基準について - kazuhoのメモ置き場

[oktnzm]

クッソ読みにくい構造化もOOもNG

[bongkura]

コールしまくりファイルまたがりまくりのIDE無いと読めないようなオブジェクト指向大好きなソースが大嫌いなヘボプログラマーなので言い訳ができてよかったです

[katzchang]

氷山の一角に過ぎない感がある。

[nippondanji]

理論的（論理的ではなく）で面白い話。関数内の複雑度とコールグラフの複雑度は別のレイヤーの話なので直接比較は難しいと思うんだけど、それは経験とかセンスで判断するということなんだろうか。

[ruicc]

実感としてわからなくもないが...オブジェクト指向は環境引きずり過ぎなので、DRY化が間違い易いのだと思う。「暗黙知を増やすDRY」とはまさにそのパターンだと思っていて、「暗黙の環境の前提」があるならばそもそもそ

[hoisjp]

コールグラフは複雑化する モジュールをまたぐDRY化を行うと、モジュール間の依存関係も複雑化する

[mizchi]

わかる

[osnq]

"コールグラフは複雑化する"これはわかるわ。意味単位で分離されて、副作用が無く、ブラックボックスで扱えられば良いですよね。

[lesamoureuses]

“モジュール間の複雑性上昇を抑えるため、DRY化はできるだけ局所的に行う”