コードは育つ、僕も育つ、 PHPと歩んだ設計物語

PHPカンファレンス関西2025登壇資料

Transcript

1. © 2012-2025 BASE, Inc. 2025/07/19 PHPカンファレンス関西2025 コードは育つ、僕も育つ、 PHPと歩んだ設計物語 1
2. © 2012-2023 BASE, Inc. 今日の話 2
3. © 2012-2025 BASE, Inc. 3 「失敗と試行錯誤は資産だ」
4. © 2012-2025 BASE, Inc. 4 氏名：Capi(かぴ) 所属：BASE株式会社(9ヶ月目) 職種：Webアプリケーションエンジニア 趣味：飲酒、美術館にいく、技術系情報の収集 前職は受託で新規開発や運用保守、リアーキテク トPJをメンバーや開発リーダーとして経験。 現在はデザイン刷新PJにメンバーとして挑戦中。 カピバラになりたい ysssssss98 自己紹介 You-saku
5. © 2012-2025 BASE, Inc. 目次 5 • はじめに • 今回のゴール • 失敗が生み出した過去のコードたち • 改善のためにできること • 奮闘の結果と得たもの • まとめ
6. © 2012-2023 BASE, Inc. はじめに 6
7. © 2012-2025 BASE, Inc. はじめに 7 今回の内容は個人の一意見です。正論を振りかざすつもりは一切ありません。 前職の話が多めです。 スライドに載ってるコードはサンプルです。 アプリケーション設計というか実装改善の要素が大きいかもしれません。 時間の都合で軽くの紹介が多いです。 深掘りは懇親会など個別にしていただけると幸いです。喜んで答えます。
8. © 2012-2023 BASE, Inc. 今回のゴール 8
9. © 2012-2025 BASE, Inc. 今回のゴール 9 １ ２ 失敗を改善するための奮闘を紹介 自分が書いた過去の失敗コードを紹介 ３ 奮闘の結果と得たものを紹介
10. © 2012-2023 BASE, Inc. 失敗が生み出した 過去のコードたち 10
11. © 2012-2025 BASE, Inc. 失敗が生み出した過去のコードたち 11 １ ２ とりあえず別ファイルに切り出してみただけ Fatなクラス ３ 責務を分けられない
12. © 2012-2025 BASE, Inc. 失敗が生み出した過去のコードたち 12 1. Fatなクラス 右の画像はUserモデルクラスです(見えなくて大丈夫です)。 Q. なぜこうなった？ A. なんでもモデルに書きすぎ 良くあるものはFatModel, FatController ちなみに最長で625行のクラス(コントローラー)を作った経験があります。
13. © 2012-2025 BASE, Inc. 失敗が生み出した過去のコードたち 13 2. とりあえず別ファイルに切り出しただけ 切り出し方はきちんと考えましょう。 例) よし！625行のコントローラーを短くしよう！ → 短くなったが…… 自分　: 「オブジェクト指向？を使ってスッキリだ」 他の人: 「このコードは何？なぜこの場所にある？」 行数を減らし可読性は上がったが、まだ足りない。 コードを短くすることこそが正しいと思い込んでいた。
14. © 2012-2025 BASE, Inc. 失敗が生み出した過去のコードたち 14 3. 責務を分けられない システム面の責務分離も大事です。 例) DB保存とメール送信が同じTXに存在 = 単一責任の原則を意識できていない。 同じTXに入れることしか知らなかった(無知)。
15. © 2012-2023 BASE, Inc. 改善のためにできること 15
16. © 2012-2025 BASE, Inc. 改善のためにできること 16 １ ２ ドキュメントなど明文化の実施 テストコードと定期的な改善習慣と工夫 ３ 設計を知る。小さく導入する
17. © 2012-2025 BASE, Inc. 改善のためにできること 17 1. テストコードを書く 個人的な意見 1.結合テストを書いてみてほしい(HTTPテ ストのI/Oは変わりにくいはず……) 2.結合テストでの気づきは多い 3.再構成した際のセーフティネットを作ろ う テストコードは改善の種になります 違和感を次の改善へ繋げる backendのI/O自体は 変わりにくい(はず) テストは設計にフィードバックを与えます 注意 : 結合テストはコストが高く辛いことが多い
18. © 2012-2025 BASE, Inc. 改善のためにできること 18 2. コメントを書く 極端な例だが、これでは足りない。 コメントを読んで「どう直していくか」を1から 考えなくてはいけない。 // TODO: あとで直す
19. © 2012-2025 BASE, Inc. 改善のためにできること 19 「こうしたい」を伝えられるように書く // TODO: Userモデルの責務が増えている // 可能であれば、責務を分割してリファクタリングすることを検討したい // // 例) // 1. ユーザーとアカウントの概念が混在しているため明確に分ける // 2. ログイン履歴の保存処理をイベントとして切り出せそう // 3. ユーザーが持つ信用スコアを別クラスへ切り出す(値オブジェクト？) 未来に改善をしようとしてくれる人へ 当時考えていた方針を伝えられる。 (当時のコメントが正解か否かは別)
20. © 2012-2025 BASE, Inc. 改善のためにできること 20 未来にこのコードを読む人は過去の記憶をなくした自分かも知れないし 他の人かも知れないことを忘れず…… git blameで確認 誰だ！！ これ書いたやつ！！ ワシやないかい
21. © 2012-2025 BASE, Inc. 改善のためにできること 21 注意 フロントエンドはコメントが表示さ れてしまう場合があります。 気をつけましょう。 // TODO: TODOの削除機能を追加する // TODO: TODOの編集機能を追加する // TODO: TODOの完了機能を追加する
22. © 2012-2025 BASE, Inc. 改善のためにできること 22 3. ボーイスカウト・ルール 残念ながら「いつかやろう」の”いつか”は なかなか来ません。最悪一生来ません。 タイミングを常にうかがいましょう。 ボーイスカウト・ルール, https://プログラマが知るべきこと.com/エッセイ/ボーイスカウト-ルール, (2025/07/19) 注意 過剰なボーイスカウトに気をつける。 となり山のキャンプ場まで綺麗にしに行か ないこと。
23. © 2012-2025 BASE, Inc. 改善のためにできること 23 4.当時の状況をドキュメントに残しておく ADR(アーキテクトディシジョンレコード)のようなものイメージしてください。 個人的には中規模以上の新規機能実装をする際に作るのをオススメします。 当時の状況とは？ • プロジェクトの納期 • 既存実装の状況 • プロジェクトメンバーのざっくりとしたスキルセット • 実装候補と各候補のメリットデメリット • 最終的な意思決定 大事なことは「どうしてその実装にしたのか」に回答できる証拠を残すこと
24. © 2012-2025 BASE, Inc. 改善のためにできること 24 当時の記録を残すことで「決して最初から良くない実装をするつもりはなかっ たこと」を伝えられるようにしましょう。 過去の記録を読む 誰だ！！ これ書いたやつ！！ これは当時の 最適解だったのか
25. © 2012-2025 BASE, Inc. 改善のためにできること 25 5. 設計を学ぶ 世の中にたくさん書籍や記事があります。 自分は右図のフローチャートで学びました。一例です。 ※設計以外も学ぶことでより設計の大切さを知ることができます。 オブジェクト指向 デザインパターン レイヤードアーキテクチャ クリーンアーキテクチャ ドメイン駆動設計 ※これと別で可読性やリファクタリングや運用保守、ソフトウェア工学を学ぶ システムアーキテクチャ 継続改善のモチベ
26. © 2012-2025 BASE, Inc. 改善のためにできること 26 自分が使うフレームワークの思想を知ることも大事(Laravelなら下記とか) 自社フレームワークでも思想を理解しましょう(思想がない場合はごめんなさい) 私の愛したLaravel 〜レールを超えたその先へ〜, https://fortee.jp/phperkaigi-2025/proposal/3ff0f775-9601-4bf6-a1cf-9911b11787b3, (2025/07/19)
27. © 2012-2025 BASE, Inc. 改善のためにできること 27 6.スモールステップでの改善 実例) 新機能でメール送信のパターンが増えそうになった時 メール送信をイベント駆動にする きっかけにできるじゃん！ まずは今回の場所だけやろう 実装完了後 他の類似箇所も イベント駆動に変えられる！ 新技術の導入経験できて 楽しかった！
28. © 2012-2023 BASE, Inc. 奮闘の結果と得たもの 28
29. © 2012-2025 BASE, Inc. 奮闘の結果と得たもの 29 １ ２ 既存メンバーだけでなく新メンバーも既存システムに リスペクトを持ってくれる環境になった 過去の負債を少しづつではあるが確実に解消できた ３ 技術に対する向上心と未来を見据えた新技術や仕組み の導入提案がチーム内でたくさん出てきた
30. © 2012-2023 BASE, Inc. まとめ 30
31. © 2012-2025 BASE, Inc. まとめ 31 最初の設計や実装をミスしても改善していくことは可能。 当時の最適解を選んだ決断を否定していけない。 「過去を受け入れ改善し続けること」「未来に現れる改善者の負担を減らすこ と」は大事。改善が継続できる仕組みを整えよう。 学び続けよう。新しい挑戦をスモールステップで導入していこう。継続力也。
32. © 2012-2023 BASE, Inc. 最後に 32
33. © 2012-2025 BASE, Inc. それでも、失敗は資産だ 33 自分は「失敗は資産になる」と考えています(失敗を美化することが良いとは思 いませんが……)。今日の発表が誰かの何かのきっかけとなったら幸いです。 BASEでは現在リアーキテクトが進行しています。自分は過去の経験を活かして 今後リアーキテクトに挑戦していきたいです。 モジュラーモノリスでスケーラブルなシステムを設計・実装する - BASEリアーキテクチャのい ま,https://speakerdeck.com/panda_program/base-modular-monolit h, (2025/07/19) 過去カンファレンスのスライドはこちら (他にもたくさんあります)
34. © 2012-2025 BASE, Inc. 34 I have not failed, I’ve just found 10,000 ways that won’t work 私は失敗したことはない。 うまくいかない方法を10,000通り見つけただけだ。 Thomas Alva Edison それでも、失敗は資産だ トーマス・エジソン, https://ja.wikipedia.org/wiki/トーマス・エジソン, (2025/07/19)
35. © 2012-2025 BASE, Inc. Appendix 35 自分が読んできたアプリケーション設計の本 • 現場で役立つシステム設計の原則 • ちょうぜつソフトウェア設計入門 • Web API: The Good Parts • わかる！ドメイン駆動設計 〜もちこちゃんの大冒険 • ドメイン駆動設計 モデリング/実装ガイド • ドメイン駆動設計入門 ボトムアップでわかる！ ドメイン駆動設計の基本 • オブジェクト設計スタイルガイド
36. © 2012-2025 BASE, Inc. Appendix 36 自分が読んできたアプリケーション設計以外のおすすめ副読書 • UNIXという考え方 • レガシーソフトウェア改善ガイド • テスト駆動設計 • 読みやすいコードのガイドライン • システム運用アンチパターン • ルールズ・オブ・プログラミング • Team Geek • 失敗の科学 • GitLabに学ぶ世界最先端のリモート組織のつくりかた • エンジニアのためのドキュメントライティング