「開発現場で役立たせるための設計原則とパターン」をオススメできない理由 - うさぎ組

「開発現場で役立たせるための設計原則とパターン」は設計をリードするには悪手である このエントリーは 実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く に対する返答です。 件のエントリーおよびスライドを拝見したときの私の感想は「昔の自分だったらこのようにレクチャーしたであろうけど、いまの私ならこうしない。そして、このようにレクチャーするのは時に問題がある」というものでした。 私は発表を見ていたわけではなかったので、スライドだけを拝見したときにはエントリーとしてまとめるのはどうかと思ったのですが、発表者が丁寧な解説付きの記事をあげてくれていたので、私の考えをまとめるための情報を揃ったと判断した次第です。 そして発表者様のエントリーを読んでも私の感想は変わりませんでした。 まず、件のスライ

[n314]

言いたいことはわかるけど、また抽象的な話の空中戦に戻ってるような。

[nkgt_chkonk]

3回読んだけど良いことが書かれていると思った。「問題によって適切な構造は変わる」というときに「じゃあその変化する問題にどうやって対応するんですか」って話がこんどは課題になるということだと思う

[atsushifx]

まだ最適化するな、もう最適化するな

[kwhrtsk]

例えば単一責任原則では変更理由の発生要因が重要なんだけど、これは機能に注目しても分からない。顧客視点やシステム境界など外部要因の分析(戦略設計)が必要なんだが元記事にはそれが抜けている、ということかな。

[to4iki]

“「問題によって適切な構造は変わる」” 環境(プロダクト・人・要件 etc)は日々変化するものなので理想考えた上で現実解に落とし込む(考え続ける)ことが大事だと思っている。やり方は置いといて

[anoworl]

冒頭を読んで解決方法が提示されるエントリかと期待した

[jakalada]

すでに実装を終えた問題なく動作している機能に対して、要件が変わらない限り、設計原則に反するからといって、構造を変えるほどの変更を加える必要はない、という前提がある？

[takahiro665]

読んだ。よくわからない。

[mizoguche]

“よく変更されるような振る舞いについては簡単に書き換えられるようになっているほうが楽だし、そのときに「この機能はこんなに重要だ！」という思い込みによる具象化と抽象化をするのは、いわゆる早すぎる最適化と

[zetta1985]

“決定を遅延しながら機能するネットワークを常に作り続ける”