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

by hirobe

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

4 廣部知⽣(@tomoki2135) ● 21卒で株式会社ラクスに⼊社 ● PHPでMail Dealerの開発を⾏っている ● 彦根市⺠なのにアイコンは名古屋城 ● 最近はスト6で戦いの螺旋を登り続けています

Slide 5

Slide 5 text

5 Mail Dealerについてメール共有管理システム 14年連続シェアNo.1（2009〜2022）※ 歴史は更に⻑く、2001年4⽉に販売開始 Laravelは2011年リリースなので、10歳年上 ※出典：ITR「ITR Market View：メール∕Webマーケティング市場2023」メール処理市場：ベンダー別売上⾦額推移およびシェア2009－2022年度（予測値）

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 Mail Dealerの”負債” ● ルーティングが存在せず、〇〇.phpに直接アクセス ● ロジックは〇〇.phpのグローバル領域に直書き ○ クラスの概念も（ほぼ）存在しない処理が上から下に流れるだけ ● テンプレートエンジンは未使⽤ ○ HTMLの出⼒は print や echo で⾏われている ● 当然、⼗分な⾃動テストも存在しない（特にUI周り）

Slide 9

Slide 9 text

9 Mail Dealerの”負債” ● ルーティングが存在せず〇〇.phpに直接アクセス maildealer ├ lib └ public ├ img ├ css └ php ├ index.php ├ login.php ├ maillist.php ……

Slide 10

Slide 10 text

10 Mail Dealerの”負債” ● ロジックは〇〇.phpのグローバル領域に直書き ● クラスの概念も（ほぼ）存在しない ● テンプレートエンジンは未使⽤ <*ページ特有のスクリプトが記述されている EOF; echo << サンプルページ {$js} EOF;

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 実装⽅針 Action Responder Domain HTTP request HTTP response ビジネスロジック呼び出しここにビューを移植ここにロジックを移植 Blade Vue

Slide 24

Slide 24 text

Slide 25

Slide 25 text

25 実装⽅針 Action Responder Domain HTTP request HTTP response ビジネスロジック呼び出しここにビューを移植ここにロジックを移植 Blade Vue

Slide 26

Slide 26 text

26 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化参照渡しやグローバル変数の利⽤は許容する 2. 旧UIを利⽤して、動作確認 3. 処理ごとにActionを分割し、新UIからは個別のエンドポイントを呼び出して処理を⾏う

Slide 27

Slide 27 text

27 旧UI

Slide 28

Slide 28 text

28 旧UI 旧ロジッククラスメソッド化

Slide 29

Slide 29 text

29 旧UI メソッド化置き換え

Slide 30

Slide 30 text

30 旧UI メソッド化置き換え

Slide 31

Slide 31 text

31 旧UI メソッド化置き換え

Slide 32

Slide 32 text

32 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3. 処理ごとにActionを分割し、新UIからは個別のエンドポイントを呼び出して処理を⾏う

Slide 33

Slide 33 text

33 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3. 処理ごとにActionを分割し、新UIからは個別のエンドポイントを呼び出して処理を⾏う

Slide 34

Slide 34 text

34 /add-comment にリクエスト

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

37 ビジネスロジックをLaravelに”載せる” 1. 処理のまとまりごとに、クラスメソッド化 a. PhpStormの機能を使って、機械的にメソッド化参照渡しやグローバル変数を利⽤することを許容する 2. 旧UIを利⽤して、動作確認 3. 処理ごとにActionを分割し、新UIからは個別のエンドポイントを呼び出して処理を⾏う既存コードを維持できる！

Slide 38

Slide 38 text

Slide 39

Slide 39 text

39 実装⽅針 Action Responder Domain HTTP request HTTP response ビジネスロジック呼び出しここにビューを移植ここにロジックを移植 Blade Vue

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

48 Bladeでレンダリング

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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