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.4k
フレームワークが存在しない時代からのレガシープロダクトを、 Laravelに”載せる”実装戦略
PHPConference2023登壇資料です
hirobe
October 08, 2023
Tweet
Share
More Decks by hirobe
See All by hirobe
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
980
PHPでOfficeファイルを取り扱う! PHP Officeライブラリを プロダクトに組み込んだ話
hirobe1999
0
1.8k
PHP8.1で、リソースがオブジェクトに!? マイナーリリースの変更が レガシープロダクトに与えた影響
hirobe1999
0
1.2k
フレームワークが存在しない時代からのレガシープロダクトを、 Laravelに”載せる”実装戦略
hirobe1999
0
1.6k
新卒PHPer奮闘記 ~配属されたのは3歳違いのプロダクト!?~ / phperkaigi-2022-lt
hirobe1999
0
1.4k
Other Decks in Programming
See All in Programming
Stackless и stackful? Корутины и асинхронность в Go
lamodatech
0
1.2k
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
230
Jaspr Dart Web Framework 박제창 @Devfest 2024
itsmedreamwalker
0
140
BEエンジニアがFEの業務をできるようになるまでにやったこと
yoshida_ryushin
0
100
menu基盤チームによるGoogle Cloudの活用事例~Application Integration, Cloud Tasks編~
yoshifumi_ishikura
0
140
PHPカンファレンス 2024|共創を加速するための若手の技術挑戦
weddingpark
0
120
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
800
Внедряем бюджетирование, или Как сделать хорошо?
lamodatech
0
880
コンテナをたくさん詰め込んだシステムとランタイムの変化
makihiro
1
180
php-conference-japan-2024
tasuku43
0
410
React 19でお手軽にCSS-in-JSを自作する
yukukotani
5
540
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
9
2.3k
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
32
6.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
112
50k
Making Projects Easy
brettharned
116
6k
Writing Fast Ruby
sferik
628
61k
Side Projects
sachag
452
42k
Docker and Python
trallard
43
3.2k
Adopting Sorbet at Scale
ufuk
74
9.1k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3.1k
How GitHub (no longer) Works
holman
312
140k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
97
17k
Building an army of robots
kneath
302
44k
GitHub's CSS Performance
jonrohan
1030
460k
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