フレームワークが存在しない時代からのレガシープロダクトを、 Laravelに”載せる”実装戦略

PHPConference2023登壇資料です

Transcript

1. © RAKUS Co., Ltd. ノンフレームワークのレガシープロダクトを、 Laravelに"載せる"実装戦略と、その後の世界。 #PHPConference2023 廣部知⽣ 2023/10/08 1
2. 2 話すこと • ⾃⼰紹介 • Laravel導⼊の経緯 • Laravelに”載せる”実装戦略 • Laravelに”載せる”⼿法の紹介 • ”載せた”後の世界
3. © RAKUS Co., Ltd. 3 ⾃⼰紹介 #PHPConference2023
4. 4 廣部知⽣(@tomoki2135) • 21卒で株式会社ラクスに⼊社 • PHPでMail Dealerの開発を⾏っている • 彦根市⺠なのにアイコンは名古屋城 • 最近はスト6で戦いの螺旋を 登り続けています
5. 5 Mail Dealerについて メール共有管理システム 14年連続シェアNo.1（2009〜2022）※ 歴史は更に⻑く、2001年4⽉に販売開始 Laravelは2011年リリースなので、10歳年上 ※出典：ITR「ITR Market View：メール∕Webマーケティング市場2023」  メール処理市場：ベンダー別売上⾦額推移およびシェア2009－2022年度（予測値）
6. © RAKUS Co., Ltd. 6 Q.なぜそんなプロダクトにLaravelを？ 🤔 #PHPConference2023
7. © RAKUS Co., Ltd. 7 Laravel導⼊の経緯 #PHPConference2023
8. 8 Mail Dealerの”負債” • ルーティングが存在せず、〇〇.phpに直接アクセス • ロジックは〇〇.phpのグローバル領域に直書き ◦ クラスの概念も（ほぼ）存在しない 処理が上から下に流れるだけ • テンプレートエンジンは未使⽤ ◦ HTMLの出⼒は print や echo で⾏われている • 当然、⼗分な⾃動テストも存在しない（特にUI周り）
9. 9 Mail Dealerの”負債” • ルーティングが存在せず 〇〇.phpに直接アクセス maildealer ├ lib └ public   ├ img   ├ css   └ php     ├ index.php     ├ login.php     ├ maillist.php ……
10. 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;
11. © RAKUS Co., Ltd. 11 󰤇 #PHPConference2023
12. 12 新UI導⼊要望 ‧現⾏のUIはデザインが古臭くて  印象があまり良くなくて…… ‧モダンな今⾵のUIにしたいです！ ‧旧UI（現⾏UI）の機能はすべて  新UIにも実装してください！ ‧顧客インパクト⼤きいから  旧UIもしばらく残したいです
13. © RAKUS Co., Ltd. 13 󰤇 #PHPConference2023
14. © RAKUS Co., Ltd. 14 現在の負債を抱えたままでは 実装‧保守ともに厳しい…… #PHPConference2023
15. 15 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向の考えに則った⼀般的な アーキテクチャに変更し、保守性を向上させる • 短期的⽬的 ◦ 旧UIの機能を維持しながら新UIを素早くリリース
16. © RAKUS Co., Ltd. 16 🤔 #PHPConference2023
17. © RAKUS Co., Ltd. 17 ⽬的を達成するための実装戦略 Laravelに”載せる” #PHPConference2023
18. 18 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向を考えに則った⼀般的な アーキテクチャに変更 • 短期的⽬的 ◦ 旧UIの機能を維持しながら新UIを素早くリリース
19. 19 Laravelに”載せる”ための設計 • アーキテクチャにADRパターンを採⽤（⻑期的⽬的） ◦ 短期的⽬的達成のために都合が良かった（後述） ◦ 少なくとも、体系⽴ったアーキテクチャを採⽤するだけで 保守性が向上する
20. 20 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向を考えに則った⼀般的な アーキテクチャに変更 • 短期的⽬的 ◦ 旧UIの機能を維持しながら新UIを素早くリリース
21. 21 Laravelに”載せる”ための設計 • 既存コードを、できる限り維持する（短期的⽬的） ◦ 既存コードをそのまま移植することができれば 理論上機能は同じ ◦ リファクタリングは⾏わない テストがないため、”既存機能と同じ”を担保できない →不具合までも移植する ◦ あくまで”Laravel上で動くこと”を⽬標とする
22. 22 Laravelに”載せる”ための課題 • 最⼤の課題は、ビューロジックとビジネスロジックが ⼀体化していること • もはや、ビューとロジックを 分 離 するのは ⼀ 般 的 Laravelも分離が前提のフレームワーク • ビューとロジックを分離しないと フレームワークに載せられない ビューとロジックを分離するしか無い！
23. 23 実装⽅針 Action Responder Domain HTTP request HTTP response ビジネスロジック 呼び出し ここにビューを移植 ここにロジックを移植 Blade Vue
24. © RAKUS Co., Ltd. 24 ビジネスロジックを Laravelに”載せる” #PHPConference2023
25. 25 実装⽅針 Action Responder Domain HTTP request HTTP response ビジネスロジック 呼び出し ここにビューを移植 ここにロジックを移植 Blade Vue
26. 26 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化 参照渡しやグローバル変数の利⽤は許容する 2. 旧UIを利⽤して、動作確認 3. 処理ごとにActionを分割し、新UIからは 個別のエンドポイントを呼び出して処理を⾏う
27. 27 旧UI
28. 28 旧UI 旧ロジッククラス メソッド化
29. 29 旧UI メソッド化 置き換え
30. 30 旧UI メソッド化 置き換え
31. 31 旧UI メソッド化 置き換え
32. 32 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化 参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3. 処理ごとにActionを分割し、新UIからは 個別のエンドポイントを呼び出して処理を⾏う
33. 33 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化 参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3. 処理ごとにActionを分割し、新UIからは 個別のエンドポイントを呼び出して処理を⾏う
34. 34 /add-comment に リクエスト
35. 35 コメント登録Domainが呼ばれる
36. 36 旧UIと共通のメソッドが呼ばれる
37. 37 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化 参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3. 処理ごとにActionを分割し、新UIからは 個別のエンドポイントを呼び出して処理を⾏う 既存コードを 維持できる！
38. © RAKUS Co., Ltd. 38 ビューロジックを Laravelに”載せる” #PHPConference2023
39. 39 実装⽅針 Action Responder Domain HTTP request HTTP response ビジネスロジック 呼び出し ここにビューを移植 ここにロジックを移植 Blade Vue
40. 40 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する 例：ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング
41. 41 旧 旧ロジックのHTML出⼒処理はすべてコメントアウト
42. 42 新 旧ロジックのHTML出⼒処理はすべてコメントアウト
43. 43 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する 例：ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング
44. 44 旧 新UIでも必要な実データのみ、配列に格納する
45. 45 新 新UIでも必要な実データのみ、配列に格納する
46. 46 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する 例：ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング
47. 47 実データをまとめた配列を返り値に
48. 48 Bladeでレンダリング
49. 49 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する 例：ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング 既存コードを 維持できる！
50. 50 効果 • 移植がスピーディになった ◦ 新UIのためにコードを書き直す必要が（ほぼ）ない ◦ 旧UIの構造が（ほぼ）そのまま維持されているので 移植忘れも少なくできた • ⾃動テストが可能になった ◦ 旧：表⽰データがそのまま出⼒されており、テストが困難 ◦ 新：データが返り値として表現されるため、テストが容易
51. 51 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向を利⽤した⼀般的な アーキテクチャに変更 • 短期的⽬的 ◦ 旧UIの機能を維持しながら新UIを素早くリリース 達 成 達 成
52. © RAKUS Co., Ltd. 52 プロジェクト⼤成功！ めでたしめでたし……？ #PHPConference2023
53. © RAKUS Co., Ltd. 53 ソフトウェア開発は、終わらない #PHPConference2023
54. © RAKUS Co., Ltd. 54 ”載せた”後の世界 #PHPConference2023
55. 55 Good • ビューとビジネスロジックの分割によって フロントエンドとバックエンドが分業ができるようになった • ロジックをベタ書きする必要がなくなり オブジェクト指向化が進んだ • 新機能はテストが⾃動テストが容易になった
56. © RAKUS Co., Ltd. 56 光があれば、闇もある #PHPConference2023
57. 57 Bad • ⾏ったのは、あくまで移植 →コードの改善が⾏われたわけではないので  レガシーな書き⽅や、グローバル変数が多く残る • 全ての画⾯が移植されたわけではないし、旧UIの保守もいる →開発に必要な学習や保守コストが増えた
58. 58 今後の展望 • テストが書けるようになったので、テストを作成して リファクタリングを進めていく • 今後の新機能は基本新UIのみ、旧UIはクローズ予定   ノンフレームワークがLaravelに載ったことが⼤きな⼀歩 今後はオブジェクト指向に寄せていく
59. © RAKUS Co., Ltd. 59 千⾥の道も⼀歩から めでたしめでたし #PHPConference2023