Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フレームワークが存在しない時代からのレガシープロダクトを、 Laravelに”載せる”実装戦略
Search
hirobe
October 08, 2023
Programming
0
1.3k
フレームワークが存在しない時代からのレガシープロダクトを、 Laravelに”載せる”実装戦略
PHPConference2023登壇資料です
hirobe
October 08, 2023
Tweet
Share
More Decks by hirobe
See All by hirobe
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
450
PHPでOfficeファイルを取り扱う! PHP Officeライブラリを プロダクトに組み込んだ話
hirobe1999
0
1.8k
PHP8.1で、リソースがオブジェクトに!? マイナーリリースの変更が レガシープロダクトに与えた影響
hirobe1999
0
1.2k
フレームワークが存在しない時代からのレガシープロダクトを、 Laravelに”載せる”実装戦略
hirobe1999
0
1.5k
新卒PHPer奮闘記 ~配属されたのは3歳違いのプロダクト!?~ / phperkaigi-2022-lt
hirobe1999
0
1.4k
Other Decks in Programming
See All in Programming
talk-with-local-llm-with-web-streams-api
kbaba1001
0
180
KubeCon + CloudNativeCon NA 2024 Overviewat Kubernetes Meetup Tokyo #68 / amsy810_k8sjp68
masayaaoyama
0
250
menu基盤チームによるGoogle Cloudの活用事例~Application Integration, Cloud Tasks編~
yoshifumi_ishikura
0
110
rails stats で紐解く ANDPAD のイマを支える技術たち
andpad
1
290
良いユニットテストを書こう
mototakatsu
5
2k
Stackless и stackful? Корутины и асинхронность в Go
lamodatech
0
720
SymfonyCon Vienna 2025: Twig, still relevant in 2025?
fabpot
3
1.2k
return文におけるstd::moveについて
onihusube
1
1k
Асинхронность неизбежна: как мы проектировали сервис уведомлений
lamodatech
0
720
Recoilを剥がしている話
kirik
5
6.6k
php-conference-japan-2024
tasuku43
0
230
テストコードのガイドライン 〜作成から運用まで〜
riku929hr
1
170
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
97
A Tale of Four Properties
chriscoyier
157
23k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
32
2.7k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
A Philosophy of Restraint
colly
203
16k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
For a Future-Friendly Web
brad_frost
175
9.4k
Optimizing for Happiness
mojombo
376
70k
Transcript
© RAKUS Co., Ltd. ノンフレームワークのレガシープロダクトを、 Laravelに"載せる"実装戦略と、その後の世界。 #PHPConference2023 廣部知⽣ 2023/10/08 1
2 話すこと • ⾃⼰紹介 • Laravel導⼊の経緯 • Laravelに”載せる”実装戦略 • Laravelに”載せる”⼿法の紹介
• ”載せた”後の世界
© RAKUS Co., Ltd. 3 ⾃⼰紹介 #PHPConference2023
4 廣部知⽣(@tomoki2135) • 21卒で株式会社ラクスに⼊社 • PHPでMail Dealerの開発を⾏っている • 彦根市⺠なのにアイコンは名古屋城 •
最近はスト6で戦いの螺旋を 登り続けています
5 Mail Dealerについて メール共有管理システム 14年連続シェアNo.1(2009〜2022)※ 歴史は更に⻑く、2001年4⽉に販売開始 Laravelは2011年リリースなので、10歳年上 ※出典:ITR「ITR Market View:メール∕Webマーケティング市場2023」
メール処理市場:ベンダー別売上⾦額推移およびシェア2009-2022年度(予測値)
© RAKUS Co., Ltd. 6 Q.なぜそんなプロダクトにLaravelを? 🤔 #PHPConference2023
© RAKUS Co., Ltd. 7 Laravel導⼊の経緯 #PHPConference2023
8 Mail Dealerの”負債” • ルーティングが存在せず、〇〇.phpに直接アクセス • ロジックは〇〇.phpのグローバル領域に直書き ◦ クラスの概念も(ほぼ)存在しない 処理が上から下に流れるだけ
• テンプレートエンジンは未使⽤ ◦ HTMLの出⼒は print や echo で⾏われている • 当然、⼗分な⾃動テストも存在しない(特にUI周り)
9 Mail Dealerの”負債” • ルーティングが存在せず 〇〇.phpに直接アクセス maildealer ├ lib └
public ├ img ├ css └ php ├ index.php ├ login.php ├ maillist.php ……
10 Mail Dealerの”負債” • ロジックは〇〇.phpの グローバル領域に直書き • クラスの概念も(ほぼ) 存在しない •
テンプレートエンジンは 未使⽤ <?php include 'common.php'; if ($_POST('comment')) { </ コメント追加処理 } elseif ($_POST('folderid')) { </ フォルダ移動処理 } $js = <<<EOF <script> <*ページ特有のスクリプトが記述されている</ </script> EOF; echo <<<EOF <head> <title>サンプルページ</title> {$js} </head> EOF;
© RAKUS Co., Ltd. 11 #PHPConference2023
12 新UI導⼊要望 ‧現⾏のUIはデザインが古臭くて 印象があまり良くなくて…… ‧モダンな今⾵のUIにしたいです! ‧旧UI(現⾏UI)の機能はすべて 新UIにも実装してください! ‧顧客インパクト⼤きいから 旧UIもしばらく残したいです
© RAKUS Co., Ltd. 13 #PHPConference2023
© RAKUS Co., Ltd. 14 現在の負債を抱えたままでは 実装‧保守ともに厳しい…… #PHPConference2023
15 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向の考えに則った⼀般的な アーキテクチャに変更し、保守性を向上させる • 短期的⽬的 ◦
旧UIの機能を維持しながら新UIを素早くリリース
© RAKUS Co., Ltd. 16 🤔 #PHPConference2023
© RAKUS Co., Ltd. 17 ⽬的を達成するための実装戦略 Laravelに”載せる” #PHPConference2023
18 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向を考えに則った⼀般的な アーキテクチャに変更 • 短期的⽬的 ◦
旧UIの機能を維持しながら新UIを素早くリリース
19 Laravelに”載せる”ための設計 • アーキテクチャにADRパターンを採⽤(⻑期的⽬的) ◦ 短期的⽬的達成のために都合が良かった(後述) ◦ 少なくとも、体系⽴ったアーキテクチャを採⽤するだけで 保守性が向上する
20 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向を考えに則った⼀般的な アーキテクチャに変更 • 短期的⽬的 ◦
旧UIの機能を維持しながら新UIを素早くリリース
21 Laravelに”載せる”ための設計 • 既存コードを、できる限り維持する(短期的⽬的) ◦ 既存コードをそのまま移植することができれば 理論上機能は同じ ◦ リファクタリングは⾏わない テストがないため、”既存機能と同じ”を担保できない
→不具合までも移植する ◦ あくまで”Laravel上で動くこと”を⽬標とする
22 Laravelに”載せる”ための課題 • 最⼤の課題は、ビューロジックとビジネスロジックが ⼀体化していること • もはや、ビューとロジックを 分 離 するのは
⼀ 般 的 Laravelも分離が前提のフレームワーク • ビューとロジックを分離しないと フレームワークに載せられない ビューとロジックを分離するしか無い!
23 実装⽅針 Action Responder Domain HTTP request HTTP response ビジネスロジック
呼び出し ここにビューを移植 ここにロジックを移植 Blade Vue
© RAKUS Co., Ltd. 24 ビジネスロジックを Laravelに”載せる” #PHPConference2023
25 実装⽅針 Action Responder Domain HTTP request HTTP response ビジネスロジック
呼び出し ここにビューを移植 ここにロジックを移植 Blade Vue
26 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化 参照渡しやグローバル変数の利⽤は許容する 2. 旧UIを利⽤して、動作確認 3.
処理ごとにActionを分割し、新UIからは 個別のエンドポイントを呼び出して処理を⾏う
27 旧UI
28 旧UI 旧ロジッククラス メソッド化
29 旧UI メソッド化 置き換え
30 旧UI メソッド化 置き換え
31 旧UI メソッド化 置き換え
32 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化 参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3.
処理ごとにActionを分割し、新UIからは 個別のエンドポイントを呼び出して処理を⾏う
33 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化 参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3.
処理ごとにActionを分割し、新UIからは 個別のエンドポイントを呼び出して処理を⾏う
34 /add-comment に リクエスト
35 コメント登録Domainが呼ばれる
36 旧UIと共通のメソッドが呼ばれる
37 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化 参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3.
処理ごとにActionを分割し、新UIからは 個別のエンドポイントを呼び出して処理を⾏う 既存コードを 維持できる!
© RAKUS Co., Ltd. 38 ビューロジックを Laravelに”載せる” #PHPConference2023
39 実装⽅針 Action Responder Domain HTTP request HTTP response ビジネスロジック
呼び出し ここにビューを移植 ここにロジックを移植 Blade Vue
40 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する 例:ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング
41 旧 旧ロジックのHTML出⼒処理はすべてコメントアウト
42 新 旧ロジックのHTML出⼒処理はすべてコメントアウト
43 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する 例:ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング
44 旧 新UIでも必要な実データのみ、配列に格納する
45 新 新UIでも必要な実データのみ、配列に格納する
46 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する 例:ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング
47 実データをまとめた配列を返り値に
48 Bladeでレンダリング
49 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する 例:ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング 既存コードを
維持できる!
50 効果 • 移植がスピーディになった ◦ 新UIのためにコードを書き直す必要が(ほぼ)ない ◦ 旧UIの構造が(ほぼ)そのまま維持されているので 移植忘れも少なくできた •
⾃動テストが可能になった ◦ 旧:表⽰データがそのまま出⼒されており、テストが困難 ◦ 新:データが返り値として表現されるため、テストが容易
51 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向を利⽤した⼀般的な アーキテクチャに変更 • 短期的⽬的 ◦
旧UIの機能を維持しながら新UIを素早くリリース 達 成 達 成
© RAKUS Co., Ltd. 52 プロジェクト⼤成功! めでたしめでたし……? #PHPConference2023
© RAKUS Co., Ltd. 53 ソフトウェア開発は、終わらない #PHPConference2023
© RAKUS Co., Ltd. 54 ”載せた”後の世界 #PHPConference2023
55 Good • ビューとビジネスロジックの分割によって フロントエンドとバックエンドが分業ができるようになった • ロジックをベタ書きする必要がなくなり オブジェクト指向化が進んだ • 新機能はテストが⾃動テストが容易になった
© RAKUS Co., Ltd. 56 光があれば、闇もある #PHPConference2023
57 Bad • ⾏ったのは、あくまで移植 →コードの改善が⾏われたわけではないので レガシーな書き⽅や、グローバル変数が多く残る • 全ての画⾯が移植されたわけではないし、旧UIの保守もいる →開発に必要な学習や保守コストが増えた
58 今後の展望 • テストが書けるようになったので、テストを作成して リファクタリングを進めていく • 今後の新機能は基本新UIのみ、旧UIはクローズ予定 ノンフレームワークがLaravelに載ったことが⼤きな⼀歩 今後はオブジェクト指向に寄せていく
© RAKUS Co., Ltd. 59 千⾥の道も⼀歩から めでたしめでたし #PHPConference2023