Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for Capi Capi
July 19, 2025
240

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

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

Avatar for Capi

Capi

July 19, 2025
Tweet

Transcript

  1. © 2012-2025 BASE, Inc. 4 氏名:Capi(かぴ) 所属:BASE株式会社(9ヶ月目) 職種:Webアプリケーションエンジニア 趣味:飲酒、美術館にいく、技術系情報の収集 前職は受託で新規開発や運用保守、リアーキテク

    トPJをメンバーや開発リーダーとして経験。 現在はデザイン刷新PJにメンバーとして挑戦中。 カピバラになりたい ysssssss98 自己紹介 You-saku
  2. © 2012-2025 BASE, Inc. 目次 5 • はじめに • 今回のゴール

    • 失敗が生み出した過去のコードたち • 改善のためにできること • 奮闘の結果と得たもの • まとめ
  3. © 2012-2025 BASE, Inc. 失敗が生み出した過去のコードたち 12 1. Fatなクラス 右の画像はUserモデルクラスです(見えなくて大丈夫です)。 Q.

    なぜこうなった? A. なんでもモデルに書きすぎ 良くあるものはFatModel, FatController ちなみに最長で625行のクラス(コントローラー)を作った経験があります。
  4. © 2012-2025 BASE, Inc. 失敗が生み出した過去のコードたち 13 2. とりあえず別ファイルに切り出しただけ 切り出し方はきちんと考えましょう。 例)

    よし!625行のコントローラーを短くしよう! → 短くなったが…… 自分 : 「オブジェクト指向?を使ってスッキリだ」 他の人: 「このコードは何?なぜこの場所にある?」 行数を減らし可読性は上がったが、まだ足りない。 コードを短くすることこそが正しいと思い込んでいた。
  5. © 2012-2025 BASE, Inc. 失敗が生み出した過去のコードたち 14 3. 責務を分けられない システム面の責務分離も大事です。 例)

    DB保存とメール送信が同じTXに存在 = 単一責任の原則を意識できていない。 同じTXに入れることしか知らなかった(無知)。
  6. © 2012-2025 BASE, Inc. 改善のためにできること 17 1. テストコードを書く 個人的な意見 1.結合テストを書いてみてほしい(HTTPテ

    ストのI/Oは変わりにくいはず……) 2.結合テストでの気づきは多い 3.再構成した際のセーフティネットを作ろ う テストコードは改善の種になります 違和感を次の改善へ繋げる backendのI/O自体は 変わりにくい(はず) テストは設計にフィードバックを与えます 注意 : 結合テストはコストが高く辛いことが多い
  7. © 2012-2025 BASE, Inc. 改善のためにできること 19 「こうしたい」を伝えられるように書く // TODO: Userモデルの責務が増えている

    // 可能であれば、責務を分割してリファクタリングすることを検討したい // // 例) // 1. ユーザーとアカウントの概念が混在しているため明確に分ける // 2. ログイン履歴の保存処理をイベントとして切り出せそう // 3. ユーザーが持つ信用スコアを別クラスへ切り出す(値オブジェクト?) 未来に改善をしようとしてくれる人へ 当時考えていた方針を伝えられる。 (当時のコメントが正解か否かは別)
  8. © 2012-2025 BASE, Inc. 改善のためにできること 21 注意 フロントエンドはコメントが表示さ れてしまう場合があります。 気をつけましょう。

    // TODO: TODOの削除機能を追加する // TODO: TODOの編集機能を追加する // TODO: TODOの完了機能を追加する
  9. © 2012-2025 BASE, Inc. 改善のためにできること 22 3. ボーイスカウト・ルール 残念ながら「いつかやろう」の”いつか”は なかなか来ません。最悪一生来ません。

    タイミングを常にうかがいましょう。 ボーイスカウト・ルール, https://プログラマが知るべきこと.com/エッセイ/ボーイスカウト-ルール, (2025/07/19) 注意 過剰なボーイスカウトに気をつける。 となり山のキャンプ場まで綺麗にしに行か ないこと。
  10. © 2012-2025 BASE, Inc. 改善のためにできること 23 4.当時の状況をドキュメントに残しておく ADR(アーキテクトディシジョンレコード)のようなものイメージしてください。 個人的には中規模以上の新規機能実装をする際に作るのをオススメします。 当時の状況とは?

    • プロジェクトの納期 • 既存実装の状況 • プロジェクトメンバーのざっくりとしたスキルセット • 実装候補と各候補のメリットデメリット • 最終的な意思決定 大事なことは「どうしてその実装にしたのか」に回答できる証拠を残すこと
  11. © 2012-2025 BASE, Inc. 改善のためにできること 25 5. 設計を学ぶ 世の中にたくさん書籍や記事があります。 自分は右図のフローチャートで学びました。一例です。

    ※設計以外も学ぶことでより設計の大切さを知ることができます。 オブジェクト指向 デザインパターン レイヤードアーキテクチャ クリーンアーキテクチャ ドメイン駆動設計 ※これと別で可読性やリファクタリングや運用保守、ソフトウェア工学を学ぶ システムアーキテクチャ 継続改善のモチベ
  12. © 2012-2025 BASE, Inc. 改善のためにできること 27 6.スモールステップでの改善 実例) 新機能でメール送信のパターンが増えそうになった時 メール送信をイベント駆動にする

    きっかけにできるじゃん! まずは今回の場所だけやろう 実装完了後 他の類似箇所も イベント駆動に変えられる! 新技術の導入経験できて 楽しかった!
  13. © 2012-2025 BASE, Inc. 奮闘の結果と得たもの 29 1 2 既存メンバーだけでなく新メンバーも既存システムに リスペクトを持ってくれる環境になった

    過去の負債を少しづつではあるが確実に解消できた 3 技術に対する向上心と未来を見据えた新技術や仕組み の導入提案がチーム内でたくさん出てきた
  14. © 2012-2025 BASE, Inc. それでも、失敗は資産だ 33 自分は「失敗は資産になる」と考えています(失敗を美化することが良いとは思 いませんが……)。今日の発表が誰かの何かのきっかけとなったら幸いです。 BASEでは現在リアーキテクトが進行しています。自分は過去の経験を活かして 今後リアーキテクトに挑戦していきたいです。

    モジュラーモノリスでスケーラブルなシステムを設計・実装する - BASEリアーキテクチャのい ま,https://speakerdeck.com/panda_program/base-modular-monolit h, (2025/07/19) 過去カンファレンスのスライドはこちら (他にもたくさんあります)
  15. © 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)
  16. © 2012-2025 BASE, Inc. Appendix 35 自分が読んできたアプリケーション設計の本 • 現場で役立つシステム設計の原則 •

    ちょうぜつソフトウェア設計入門 • Web API: The Good Parts • わかる!ドメイン駆動設計 〜もちこちゃんの大冒険 • ドメイン駆動設計 モデリング/実装ガイド • ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 • オブジェクト設計スタイルガイド
  17. © 2012-2025 BASE, Inc. Appendix 36 自分が読んできたアプリケーション設計以外のおすすめ副読書 • UNIXという考え方 •

    レガシーソフトウェア改善ガイド • テスト駆動設計 • 読みやすいコードのガイドライン • システム運用アンチパターン • ルールズ・オブ・プログラミング • Team Geek • 失敗の科学 • GitLabに学ぶ世界最先端のリモート組織のつくりかた • エンジニアのためのドキュメントライティング