今あえてDRY原則に向き合う

"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)

[mizchi]

むかし世界は一つだったんだけど裏世界が出現したことで WorldMapクラスのシングルトンを剥がしたのを思い出した

[utisam]

話の本質とはズレるけど、イスラムの人に先祖代々繋げると聞いたときはもう姓名を分ける考えは避けようと思った。 http://www.asahi-net.or.jp/~ax2s-kmtn/ref/pname/

[hatz48]

ほんとに同じことなら繰り返さない方がいいんだけど、大体は同じに見えてもちょっとずつ違ってて無理な共通化が祟ることのが多いと感じるこの頃。

[tyru]

「だんだん DRY に対してドライな態度取るようになりがち」 / 良い interface を設計してけば自然と DRY になるだけで、単純に重複排除するテクニックじゃなく結果だと思ってる

[vanbraam]

アンチDRYではなく,"正しくDRYする為にはどうしたらいいか"というスライドだった;ただ,不変(そう)な物とそうでない物を予測する難しさが依然として残る事は肝に命じておくべきかと

[magnoliak]

DRYにドライな態度

[n314]

これ両方が連絡先、性別、id、パスワード、○○を持つ、とかあるとまたまとめたくなる。

[non_117]

問題を分割して構造化するという定義よいですね

[takatama]

いつもながら分かりやすい。DRYだけなのがダメなのであって、他の設計原則も合わせて使う

[kattton]

いい話

[hachibeechan]

似たような日記書いたことあるけど、DRYは結果生じるものであって、判断に使うことはできても手段や手法に使うと終わりが始まるんや

[FromAtom]

わかりの世界だ

[side_tana]

圧倒的わかりがある

[yatmsu]

DRY原則ってコードの重複だけでなくて、ミドルウェアの設定とかドキュメントまで含んでるんですよ。https://qiita.com/yatmsu/items/b4a84c4ae78fd67a364c

[nharuki]

“DRYは悪い奴じゃない。DRY「だけ」しか考えないのが悪い”

[toritori0318]

例がわかりやすい

[take_she12]

良いスライドですね。最近プログラミングしてねぇ、、、危機感。

[kitaj]

『DRY「だけ」しか考えないのが悪い』

[kakku22]

問題の本質を捉えて素晴らしい例とともにまとめられていた．現場でもこういう場面が多々ある．これは良い

[pmint]

安易な分割が重複の原因。「○○を共通化しましょう」という発想は分割してしまってるからこそ。分割時から設計（変更できる点と変更できない点を決める作業）を考えるべき。

[seiunsky]

ちゃんとまとまってて良いなぁ

[june29]

おもしろかった / サンプルコードは Ruby っぽいけど set_first_name っていう Ruby っぽくないメソッド名を採用しているのにはなにか理由があるのかな

[Pasta-K]

いい話

[Nyoho]

実際にコードと共に本当にそれでいいのかが語られていてとても勉強になる。

[willnet]

最高にいいスライドだった

[nrtkbb]

いいスライド。

[jacoby]

共通化しすぎて変更必要なときに困るのはよくある。DRYだけじゃなく凝縮度と結合度、単一責任原則、解放閉鎖原則も考慮して設計する。

[t-cyrill]

DRYにドライになりがちで笑ったのでブクマしました😇

[itouhiro]

「DRY原則（重複を排除）だけで分割すると複雑に。凝集度（関連高いのを同じ部品化）、結合度（部品同士の影響小さく）、単一責任原則（変更理由を単一に）、開放閉鎖原則（機能追加・修正で他クラス書き換えなし）」

[koogawa]

DRYに対してドライな態度をとらずに付き合っていきたい

[bc_rikko]

"凝集度は高く/結合度は低く"

[cham510]

最初のやり方でset_first_nameをオーバーライドすれば良かっただけじゃないの？

[yassan0627]

とても良い話。

[nakag0711]

結局将来の変更をどれだけ予想できるかなんだよな

[Peranikov]

良い。DRYだけを考えた時の弊害と具体的な解決策が綺麗にまとまっている。

[lenore]

バックエンド処理を書くときは自然と実施する事が、フロント側になるとどうすべきか悩む。