## 注意事項

- 勉強会の様子はリアルタイム配信 & 後日編集した動画としてYoutubeにて公開させて頂きます
- 顔出し NG の方は遠慮なくおっしゃってください
- ゴミは各自で持ち帰ってください
- 机の上のマイクが拾ってしまうので、机ゴンゴンしないでね

## お願い

- ハッシュタグ `#ペチオブ` で勉強会の様子を X で post してね！
- [Youtube](https://www.youtube.com/@miraito) のチャンネル登録もぜひ！

###### tags: `ぺちおぶ`

## 前回のイベントはこちら
- [【難しい話禁止！！】今更聞けない設計の話 2024/05](https://phper-oop.connpass.com/event/315361/)
- [議事録](https://hackmd.io/L58moOMISMmsnNMoImX8Bw)

## 参加者

- unageel
- KAKIZAKI_m
- marina
- tdkryk ( 未着 ) ← オンラインになるって連絡ありましたー
- take44 ( 未着 )
- hiro
- hoge
- bucchi
- takuma

## 雑談テーマ

### 設計ってどういうことやるの ( unageel )

質問背景

- 詳細設計と基本設計とかあるじゃん
- どれくらい実装に近しいレベルまでやってるの？
- 要件定義とか基本設計とか、みんなどこからやってるの？

雑談

- コードベースの初期構築とかを最初にやる
- 個々の要求に対する詳細な分析は、要求ごとに毎回繰り返す
- でかい枠から考えて細かい方に
- 決まった順番があるわけじゃなくて、前後しながら循環する
- 成果物と行動を必ず交互に繋げることで、おかしい箇所が見えるようになる
- [PFD](https://www.exmotion.co.jp/solution/pa.html)
- 設計ってのはやってないってのはないんだよ
- 頭を使ってコードを書いているなら無意識レベルでも設計している
- 「FW に従う」「main に書く」でさえ決定なので、設計は存在する
- なのでいつやるとかではなく、常に行われている
- ミッションとゴールに照らして試行錯誤しながら自分らに必要なことをやるのみ
- 画一的な正解は存在しない
- でもある程度いっぱんに良いとされている先例があるので、その辺はインプットしたらいい

### 良い設計と悪い設計の判断ってどうやってるの？ ( online: swata )

- ステークホルダーの要求を反映しやすいか、では
- 費用対効果がいいこと
- みんな良し悪し考えることある？
- 影響範囲が少ないと良い設計だと思う
- 良い設計だと思って DDD したらパフォーマンスに気を配れてなかったみたいなこともあって悩ましいよね
- パフォーマンスに限定して言えば、試算する力と目標値を見極める力が必要だね
- 僕は競プロで身につけた ( hoge )
- 凝集度が高いのは良い設計だよね
- 差分がまとまって出ているとかで観測できるかもしれない
- そういうふうにメトリクスを取れるものは参考値にしやすい
- 盲目的に数値を求めるのは注意ね
- 求めるな命じよ ( Tell, Don't Ask ) に従い依存と責務の整理をしていくのが好き ( hiro )
- デメテルの法則 ( `$a->b->c` みたいに直接以上に関与するな ) にも気をつけている ( hiro )
- こういうの気をつけると凝集度が上がっていくよ
- 自分でしてない設計でも、読んで経験値しにしてくと良いと思う
- 試行数を増やしにくいことなので「こうするとこうなるのかぁ〜」と拾っていくしかない
- 美しいってなんだろう
- 思ったものが思ったところにあるとか、書き足すならここしかないとか、そういう実感があれば目安になりそう
- 名前が中身と違和感がないとか、抽象度が揃っているとかも

### 辛かった設計とか聞いてみたい ( online: まつ )

- メタプロもりもりは辛いよね ( 関数名を文字結合で決めます、みたいなやつ )
- ちょっとコーディングに話が振れるけど
- 変数スコープが広いとか再代入が多いのは辛い
- 変数名ちゃんとしてないとか
- メソッド名で中身の想像がつかないとか
- オレオレ FW は辛かった
- Read / Write が混じっているのは辛い
- e.g. `find` ついでに更新しておきました
- 時限式罠のあるもの
- e.g. 特定の日にちで壊れるもの
- 総じて、考えることが多いもの
- 戻り値のないものはテストしづらいので、できるだけ計算は純粋になるように意識している
- テストが書きやすいなら良い設計だろう
- メソッド名に `and` が入ってるのは要注意ね

### 言語によって設計って変わるの？ ( online: まつ )

- 基本設計や大枠は変わらないけど、詳細設計やコーディングは変わるよね
- PHP から Kotlin になったら、言語レベルでは違いを感じる
- 言語を変えたら設計って変わるの？
- 設計を変えたいから言語を変えるのほうが実態に近いと思う
- 言語同じでもフロントとバックで設計って変わってくるよね
- バックは堅牢さとか重視が多い
- フロントは非同期な UI を重視したり
- MySQL と DynamoDB 比べてみたら、思想が全然違った
- こういうのも影響してきそう

### 名前ってみんなどうつけてんの？ ( marina )

- 翻訳ではなくて英会話とかで調べる
- そのプロジェクトでよく使われる単語に倣う
- 英語に直せないって話と日本語でちゃんと説明できるかって話があると思う
- まず、日本語でそのメソッドを説明できるかどうか
- 説明できないってことは、そのメソッドの作りがいけてないのかも
- その上で、説明したいことが実装なのか目的なのかを確認するといい
- Not Goot「申込経路コードをソートしてカットして先頭文字を取得」
- Good「有料会員か判定したい」
- メソッドを呼ぶ人はメソッド名を見て目的に沿うものを探している

### アーキテクチャが戦略なら設計は戦術なの？ ( online: yumi )

- 戦略
- 大局的・長期的な計略
- 作戦
- 方法・策略
- 戦術
- 短期的なもの、具体的な方法・手段

### おすすめの書籍が知りたい

- [現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法](https://amzn.asia/d/8WFXYaW)
- いろいろな設計手本を整理して解説してくれる
- 読み進めていくと自然と DDD に入門できる
- [ミライトチャンネルの紹介動画](https://www.youtube.com/watch?v=MXNp8AbKQUk&list=PLyZRat-0ugZiGsplrV6ExEruIVMPll3c-)
- [ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本](https://amzn.asia/d/1f0F3LM)
- DDD と言われる設計の実装面にフォーカスした入門書
- [ドメイン駆動設計をはじめよう](https://amzn.asia/d/bklSmzc)
- 未読なので紹介できず、すいません
- [Clean Architecture](https://amzn.asia/d/5UD6lkD)
- 有名なやつ
- [テスト駆動開発](https://amzn.asia/d/9sS3YUH)
- テストに興味があるならおすすめ
- [Tidy First?](https://amzn.asia/d/aJVyOZR)
- 去年末発売
- [改訂新版　良いコード／悪いコードで学ぶ設計入門](https://amzn.asia/d/0hMBcww)
- 去年末発売
- [ユースケース駆動開発実践ガイド](https://amzn.asia/d/daSvB5Y)
- ちょっと難しいかも？
- でもめちゃおすすめ

### ミライトの動画

- https://youtu.be/ZrAaUK5LmaQ
- https://youtu.be/XzEZ1M8PsH4

### 設計って状況によって理想通りにいかないこともあるよね ( takuma )

- 時間やチームの都合で妥協せざるを得ないことってあるじゃん？

### 設計するときに使っている図のツールあったら知りたい ( bucchi )

## 告知

アンケートは[こちら](https://www.noway-form.com/ja/f/afaf2623-3b77-4d73-9293-79ca14938511)からお願いします。

次回の勉強会

https://phper-oop.connpass.com/event/343972/