【ソフトウェア設計】モジュールをどう分割するのか？

はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重

[NetPenguin]

共通処理メソッドのフリして、引数で振る舞いを変えているとか、稀によく見る。

[pyagatupa]

分け方がよくわからないので助かる

[pmint]

それ以前に、過不足ない適切な命名ができていれば、その名前で気付ける。「適切な名前の例」「名前の適度な長さ」といった謎ガイドラインがあると、気付けない。

[strawberryhunter]

「共通化とは似た構造をまとめる事ではありません。同じ役割をまとめる事です。」危険な香りがする。役割でまとめると↓「コンストラクタ引数で7つの機能を切り替えるゴミ」みたいなのが量産されそう。

[syu-m-5151]

分割しすぎていても辛いし共通化しすぎても辛い。けど、いずれGit の変更履歴からサジェストされるようになるんだろうなって思っている。

[kazokmr]

先にモデリングしたり、まずは継承は使わずに書いてから考えるみたいなことをしてる

[binary343]

システムの元となる業務を人間が作ってるから似た構造の業務はめちゃくちゃある。ライフサイクルなりで同じものなのか別のものかちゃんと判断しないとえらい目に遭う

[ihirokyx]

“共通化とは似た構造をまとめる事ではありません。同じ役割をまとめる事です。役割はビジネス分析、モデリングから導くことが出来ます。”

[peketamin]

“単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い ”

[endo_5501]

“教科書的な理想の抽象化に捕らわれず、「認知負荷を下げることに繋がるか？」 を起点とし、むしろ上げてしまうケースは 「トレードオフは成り立つか？」 を強く意識する必要があります”