勘所を押さえて良いコードを書く

Transcript

1. 勘所を押さえて良いコードを書く 2024-09-21 #GENKI.dev ﾋﾛ氏
2. 自己紹介
3. お話すること • オブジェクト指向ベースの話 • 読みやすさというより設計ベースの話 • 0 -> 1よりも1 -> 10寄りの話 • バックエンド寄りの話 • PHPベースでお話する
4. https://gihyo.jp/book/2022/978-4-297-12783-1 https://www.shoeisha.co.jp/book/detail/9784798150727
5. 良いコードってなんやろか
6. 読みやすい？ 理解しやすい？ それもあるが
7. プロダクトは作って終わりではない • 改修することがある • 運用もある • 新しく人も入ってくるしコードは読むし書くし
8. プロダクトは作って終わりではない • 改修することがある • 運用もある • 新しく人も入ってくるしコードは読むし書くし 変更に強い設計であったほうが、 多くのコストを支払わずにスケールすることができる
9. 変更に弱いあるある • 影響範囲わからん。一箇所変更したら他がこわれた。 • 改修前の調査が大変 • 想定していたより時間がかかる • などなど
10. 良いコードって 変更に強いということ （もちろん他にも定義はあると思っていて） （例えば認知負荷が低いとか）
11. 変更に強い設計の勘所 責務 凝集度 単一責任原則 疎結合 目的 etc…
12. 変更に強い設計の勘所 責務 凝集度 単一責任原則 疎結合 目的 etc…
13. 凝集度 ~common.php~
14. 凝集度 ~common.php~
15. 凝集度 ~common.php~ • Commonという名のもとに なんでもかんでも放り込まれてしまう • ~~Managerとかも然り • 本来クラスはデータとロジックの 関連性が高ければ変更に強い • なので関連するデータとロジックは クラス単位でまとめるべきである • データアクセスはインスタンス変数を使 う（凝集度を高める意味で）
16. 凝集度 ~世直し（本来であればファイルも分ける）~
17. 凝集度 ~世直し（本来であればファイルも分ける）~ • コード全体の見渡しがよくなる • データとロジックが関連することで 車輪の再発明のリスクも減らせる 番外編 • 本当は条件式も変数やインスタンスの 状態を見ないようにすべき • booleanを返す判定用のメソッドをつくる のが好ましい • 「尋ねるな、命じろ」
18. 凝集度 ~世直し（本来であればファイルも分ける）~ • コード全体の見渡しがよくなる • データとロジックが関連することで 車輪の再発明のリスクも減らせる 番外編 • 本当は条件式も変数やインスタンスの 状態を見ないようにすべき • booleanを返す判定用のメソッドをつくる のが好ましい • 「尋ねるな、命じろ」
19. ソフトウェアにおける責務とは 「ある関心事について、正常に動作するよう制御する責任」 ソフトウェアはいろんな関心事を扱う DB操作、ドメインに対する操作、アプリケーションサービス、 UI層、、、、山程あるな。 で、今回はアプリケーションの設計の話なので。 責務について
20. • クラスは単一の責任を持つという考え方 • クラスに多くの責任がのしかかると、 それだけでバグのリスクを負う。 ◦ 変更に弱い ◦ 再利用性の低下 ◦ テストカバレッジの低下 • なのでクラスは一つの責任・機能に集中すべき 単一責任原則を結局話す
21. 単一責任原則を結局話す
22. 単一責任原則を結局話す
23. 番外編
24. コメントアウト
25. https://twitter.com/t_wada/status/904916106153828352 コメントアウト
26. おこなっている処理よりも なぜそうしたか？の文脈がわかるほうが改修コストがかからない 例） // 浮動小数点をフロントに返したら表示がバグるので、 // 丸め処理をしている コメントアウト
27. Early Return
28. Early Return
29. ありがとうございました