はじめに
"どうしてあなたの共通化は間違っているのか"という、以下の@wolfmagnate(進捗ゼミ) さんの記事の第1章から3章をベースに勉強会を実施しました。
https://qiita.com/wolfmagnate/items/73c3770cf036eada630d
第1章
所感
単一責任原則(SRP)からドメイン駆動設計(DDD)へ発展するのは、だいぶ飛躍があるように思う。しかし、「単一」や「責任」をどう捉えるかは人によるので、理想は明確な指針を決めてプロジェクトに臨みたいというのはわかる。
ただ下記の懸念もある
- ドメインの範囲定義も千差万別
- プロジェクト、案件ごとに決定する必要があるので、その度に工数かかる
- ドメインエキスパートの負担が大きいDDDに時間を割きすぎて、成果までの時間が伸びるのは望ましくはない。どの程度かを判断するのはドメインエキスパートの采配にかかる。多く状況を経験するごとに最適が変わりそう。 それなりのレベル感のチームであれば、そこまでかっちり決めなくても良いのだろうとも思う。
第2章
所感
抽象度、文脈ともに心がけてはいるが、実装時に関連すると思わなかった部分が仕様変更で関連づけられて、下位モジュールの抽象度を高くして利用してしまうことがしばしばある。怠けず個別的に分割できるところはしていきたい。
分割に関するメリットの分業促進は確かに感じる。うまく抽象度を整えてくれていると深くコードを見ずに利用でき、それでいて名前や引数から何を処理しているかわかる。
「抽象化したほうが再利用性が上がるよ」と説明することは間違っている。というのは言われるまで気づかなかった。抽象化≒再利用のためと考えていた。ただ隠蔽もしすぎるとバグの時に原因究明しづらい気もする。
第3章
所感
どちらが良い悪いではなく使い分けるのが良いことはわかるが、どちらが最適かケースごとに見極めるのが難しく、それがスキルなのだと感じた。
また「どれだけいい命名をしようが、命名によってモジュールの分割の不備をごまかすことは出来ません」という言葉は図星を突かれた気分。名前に情報を詰め込みすぎた時、スルーせずしっかり分割することを意識したい。
議事録
- 全体としての所感・感想はあるか?
- 最初の認識共有は重要
- 外部の人が多く入ってくると背景が追いつけなかったりするので
- 共有すべきところは共有して、後から細かく精査する必要がないようにする
- 最初の認識共有は重要
- 今回の話を聞いての感想
- エンジニアはたいてい、真似はするが、仕様書・ドキュメントは読まない傾向
- 雑にサンプル作るとそれが元になるので後で大変になる
- なので実装の例となるサンプルをかっちり作るのが重要
- エンジニアはたいてい、真似はするが、仕様書・ドキュメントは読まない傾向