どうしてあなたの共通化は間違っているのか：目次 - Qiita

はじめに この連載では共通化とモジュール分割について扱います。この話題においてQiitaで有名な記事のひとつが@MinoDrivenさんの単一責任原則で無責任な多目的クラスを爆殺するでしょう。この記事を未読の方はまずこちらを読むことをお勧めします。本連載では、この記事に書かれているような基礎的な事項については既知であることを前提に、どのようにすれば単一責任原則にそったモジュールの分割を行うことが出来るのかをなるべく 「場合による」という言葉に逃げずに なるべく 網羅的・理論的に 解説します。 いいね、ストックをよろしくお願いします。 対象読者 設計に興味のあるエンジニア 基礎的な設計原則について学んだものの、実際の場面でどのように応用すればいいのかが掴めないエンジニア ミクロな設計についての知識を増やしたい人 ※この記事では、特定のメソッドをどのように作成するべきか、このクラスは複数の処理

[turanukimaru]

共通化を目的とすること自体が間違っていて、重複やろくに考えずに書いたコードを除去することが大事なのだが言葉遊びかもしれん。

[w1234567]

若者がずいぶんオッサンくさい話してるな、15年以上前の本だけど組込みソフトウェア開発のための構造化モデリングって本を読むとオブジェクト指向入門以前のロジックの設計方法が学べるからおすすめだよ

[zheyang]

相手を挑発して注目を集めるレトリックの題名。例）橋下徹『どうして君は友だちがいないのか』

[xlc]

タイトルで煽らないと誰も記事を読んでくれないけど、煽ったところで理解できる人は読んでくれない。分かった気の人が群がるだけ。

[versatile]

学び：共通化は自分のコードでやると楽しい

[hdampty7]

万能な設計とかなくて当初は最適化されていたものが要件が複雑化することで負債化する。ただ、多少の良し悪しは現実には存在して、少しの投資で多少の複雑化なら吸収できる設計もある。

[naoya2k]

ソフトウェアの話でいわゆるcontext( https://t.co/MtH3Rp05aF )以外のことを文脈と表現してるのはトンデモな可能性を疑ってしまう。「文脈依存性」とかって一般的な言葉なのだろうか? 自分が世間知らずなだけなのだろうか?

[n_231]

近日公開の部分が重要なのでまあ保留

[strawberryhunter]

タイトルでしか評価できないお前たち。とは言え具体的なコードが無いと長文の理屈を読むのしんどい。／個人的にはメソッドは細かく書かないでツールを使って構造で共通化するのが一番だという結論になった。

[Sampo]

挑発的なタイトルの是非ってところがブコメの論点になってるのか。そうね、おれなら目を引きつつケンカも売らないって方向で「待った！　その共通化ちょっと待った！」とかつけがち。

[otihateten3510]

難しくて僕には分からない、共通化しちゃうのははエンジニアの病気。むしろ共通化しない強い心が必要。

[devrabi]

Adaptive Codeを読みましょう

[KIKERIKI17]

構造化とかオブジェクト指向とかを[employeeクラス]とかで説明されても、実際のビジネスには適用できないのと一緒で、こういうのは【自分のやりたいことを熟知している】という前提が無いと成立しないんだよね。

[unmarshal]

「文脈依存性」が前の章で出るけど後の章で「依存」の定義や「文脈の依存」という似た表現が出てくるのね。「隠れた文脈の解消」はインターフェースに限らずDIが解決する問題だと思う。

[natu3kan]

コンテナやパレットみたく、共通規格の保守だったり所有権の問題はあるよな。スケールメリットみたいな共通化のメリットがないなら安い独自規格でいいのはそう。

[furu_ichi]

荒れそうなタイトルだなー。「必要になってから共通化を検討する」くらいのゆるい方針の方が、かえってうまくいくよ。

[Fluss_kawa]

ある程度の規模のプロダクトを作っては俯瞰して設計し直して作り直してを何回かしてだんだん勘所が掴めるようになっていくけれど、仕事ではなかなかそのサイクルを回せない。

[Magicant]

責任とか依存とか文脈とか、多くの文献で感覚的に語られがちな設計上の概念を形式化・体系化する良い試み