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

2 話すこと • ⾃⼰紹介 • Laravel導⼊の経緯 • Laravelに”載せる”実装戦略 • Laravelに”載せる”⼿法の紹介
• ”載せた”後の世界

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年度（予測値）

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;

12 新UI導⼊要望 ‧現⾏のUIはデザインが古臭くて印象があまり良くなくて…… ‧モダンな今⾵のUIにしたいです！ ‧旧UI（現⾏UI）の機能はすべて新UIにも実装してください！ ‧顧客インパクト⼤きいから旧UIもしばらく残したいです

15 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向の考えに則った⼀般的なアーキテクチャに変更し、保守性を向上させる • 短期的⽬的 ◦
旧UIの機能を維持しながら新UIを素早くリリース

18 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向を考えに則った⼀般的なアーキテクチャに変更 • 短期的⽬的 ◦

19 Laravelに”載せる”ための設計 • アーキテクチャにADRパターンを採⽤（⻑期的⽬的） ◦ 短期的⽬的達成のために都合が良かった（後述） ◦ 少なくとも、体系⽴ったアーキテクチャを採⽤するだけで保守性が向上する

20 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向を考えに則った⼀般的なアーキテクチャに変更 • 短期的⽬的 ◦

21 Laravelに”載せる”ための設計 • 既存コードを、できる限り維持する（短期的⽬的） ◦ 既存コードをそのまま移植することができれば理論上機能は同じ ◦ リファクタリングは⾏わないテストがないため、”既存機能と同じ”を担保できない
→不具合までも移植する ◦ あくまで”Laravel上で動くこと”を⽬標とする

22 Laravelに”載せる”ための課題 • 最⼤の課題は、ビューロジックとビジネスロジックが⼀体化していること • もはや、ビューとロジックを分離するのは
⼀般的 Laravelも分離が前提のフレームワーク • ビューとロジックを分離しないとフレームワークに載せられないビューとロジックを分離するしか無い！

23 実装⽅針 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 メソッド化置き換え

32 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3.

34 /add-comment にリクエスト

35 コメント登録Domainが呼ばれる

36 旧UIと共通のメソッドが呼ばれる

処理ごとにActionを分割し、新UIからは個別のエンドポイントを呼び出して処理を⾏う既存コードを維持できる！

40 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する例：ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング

41 旧旧ロジックのHTML出⼒処理はすべてコメントアウト

42 新旧ロジックのHTML出⼒処理はすべてコメントアウト

44 旧新UIでも必要な実データのみ、配列に格納する

45 新新UIでも必要な実データのみ、配列に格納する

47 実データをまとめた配列を返り値に

48 Bladeでレンダリング

49 ビューロジックをLaravelに”載せる” 1. 旧ロジックのHTML出⼒処理はすべてコメントアウト 2. 新UIでも必要な実データのみ、配列に格納する例：ユーザネームやユーザIDなど 3. 実データをまとめた配列を返り値にし、Bladeでレンダリング既存コードを
維持できる！

50 効果 • 移植がスピーディになった ◦ 新UIのためにコードを書き直す必要が（ほぼ）ない ◦ 旧UIの構造が（ほぼ）そのまま維持されているので移植忘れも少なくできた •
⾃動テストが可能になった ◦ 旧：表⽰データがそのまま出⼒されており、テストが困難 ◦ 新：データが返り値として表現されるため、テストが容易

51 Laravelの導⼊により、⼀挙両得を狙う • ⻑期的⽬的 ◦ オブジェクト指向を利⽤した⼀般的なアーキテクチャに変更 • 短期的⽬的 ◦
旧UIの機能を維持しながら新UIを素早くリリース達成達成

55 Good • ビューとビジネスロジックの分割によってフロントエンドとバックエンドが分業ができるようになった • ロジックをベタ書きする必要がなくなりオブジェクト指向化が進んだ • 新機能はテストが⾃動テストが容易になった

57 Bad • ⾏ったのは、あくまで移植 →コードの改善が⾏われたわけではないのでレガシーな書き⽅や、グローバル変数が多く残る • 全ての画⾯が移植されたわけではないし、旧UIの保守もいる →開発に必要な学習や保守コストが増えた

58 今後の展望 • テストが書けるようになったので、テストを作成してリファクタリングを進めていく • 今後の新機能は基本新UIのみ、旧UIはクローズ予定ノンフレームワークがLaravelに載ったことが⼤きな⼀歩今後はオブジェクト指向に寄せていく

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

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

More Decks by hirobe

Other Decks in Programming

Featured

Transcript