- 公開日
PHPerKaigi 2024で「10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡」を発表しました
PHPerKaigi 2024で「10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡」というタイトルで発表しました。
※ブログのリニューアル作業を優先して進めていたら、記事の公開がだいぶ遅れてしまいました💦
話した内容を一部抜粋して、記事の形で紹介します。
登場人物
- Legacy App: 移植対象となるPHPアプリケーション。
- New App: 移植先となるRailsアプリケーション。
4つの技術負債解消アプローチ
アプローチ | 家で例えると… | 説明 |
---|---|---|
リファクタリング | リノベーション | Legacy App をコンバートリファクタリング |
マイグレーション | お引越し | Legacy App → New App ヘマイグレーション |
リプレイス | 作り直し | Legacy App を全廃棄、New App をフルスクラッチ |
削除 | 解体 | Legacy App を削除 |
リファクタリング
- Pros
- ボトムアップで少しずつ安全に進められる
- Cons
- チマチマと直すので、全てをキレイにするには膨大な時間がかかる
✅ レガシー化する前の健全なシステムであれば有効なアプローチ
(※レガシー化した後では「手遅れ」なケースが多い)
マイグレーション
- Pros
- 機能単位・サービス単位・コンポーネント単位で安全に進められる
- 優先度の高い一部分だけを移植対象にすることが可能
- Cons
- 移植しやすい単位を適切に切る必要がある
- 新旧システムの互換性を考慮する必要アリ
- 新旧システムの並行運用期間が必要
- 優先度の低い機能は放置され「塩漬け」になるリスク
✅ 安全性・速度・柔軟性ともにバランスのとれたアプローチ
リプレイス
- Pros
- 一撃で負債解消できる
- 新旧システムの並行運用期間は短くできる
- Cons
- 必然的にビッグバンリリースとなりリスク大
- スコープがでかいので時間がとてもかかる
- トップダウンの意思決定(経営層の理解)が必要
✅ 成功させれば一撃必殺となるハイリスク・ハイリターンなアプローチ
削除
- Pros
- 簡単!早い!(消すだけ)
- 安い!(工数かからない)
- Cons
- 「なるほど完璧な作戦っスね―ッ 不可能だという点に目をつぶればよぉ~」
- 巻き込み事故に注意(必要ないと思って消したら実は必要だったケース)
✅ これができれば最高なアプローチ
(※現実的には全て削除は不可能で、部分的な削除になることが多い)
ソフトウェア開発の三本柱1
- バージョン管理: GitHub でソースコード管理
- テスティング: PHPUnit + E2Eテスト
- 自動化: GitHub ActionsでCI/CDを整備
3つの移植方針
- ロジックKeep移植: Legacy App のロジックを維持したまま移植。
- 仕様Keep移植: Legacy App の仕様を維持したまま移植。
- リニューアル: Legacy App をゼロからリニューアル。
リニューアルできるのであれば、さっさとリニューアルするのが吉…だけど、実際はそう簡単にリニューアルはできないので、現行の仕様を踏襲しつつ移植するのが現実的な落とし所になりがち。
結果
- 移植によってレスポンス速度が10倍に向上
- Legacy Appのコードベースを100万行削除
教訓
<技術的負債返済プロジェクト>が必要になるまで技術的負債を放置しない!
技術的負債自体は健全な開発チームにあって当然のこと。恒常的な負債返済サイクルが回っていないことが問題なので、普段から技術的負債の返済は心がける。参考発表スライド: カミナシでの技術的負債返済プロジェクトとその決断
TIPS紹介
- レガシーコードをGitHub Copilotに放り投げて解説してもらうだけでも、コードリーディングの速度・解像度がグンと上がって開発体験が良かった
- 自動テスト項目を
rspec --format documentation
でドキュメント出力し、テスターに渡しておくと、仕様の理解促進やテスト実施項目の削減にもつながって◯ - 非エンジニアにも技術的負債について理解してもらうために、「技術的負債とは何か」について話す機会をもらって、話をできたのは良かった
- 移植時の実装方針について議論が割れたときのために、実装方針の最終意思決定者を一人に決めたのは不毛な議論が減って良かった
- Code Review が遅い問題は別発表にてまとめました: Faster Pull Request Reviews 〜ハイパフォーマンスチームへの道〜 / Faster Pull Request Reviews - Speaker Deck
- あるコードが本当に使われていないかを確認するために GitHub の Org 横断検索を使うのが良かった
- クエリ:
org:{your-org} NOT is:archived {unused_code}
- クエリ:
感想
- 普段はRuby系のコミュニティに顔出すことが多かったので、PHPコミュニティとかかわれたのは良かったし、別のコミュニティからの刺激をもらえて良かった
- リアル勉強会はいいぞ!
- 謎のモチベーションがムクムク湧いてくる不思議
- 発表資料のベースデザインは Azusa 3 を使わせていただいた。便利
- 参加者からのフィードバックでは「参考になった」という言葉がいただけて良かった
- プロの声優さんに出囃子やってもらうの最高体験だった
- fortee 以前使ったときよりいろいろ機能がアップデートされて強くなっててすごかった
当日の様子
当日のXポスト
準備編
採択されたのでこちら来年のPHPerKaigiで話す予定です。PHP系イベントは初登壇なので楽しみ | 10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡 by toshimaru | プロポーザル | PHPerKaigi 2024 #phperkaigi - https://t.co/02AzYAG3cT https://t.co/GNBuf3EPzn
— toshimaru (@toshimaru_e) December 7, 2023
雑に社内研修用の資料を作り始めようと思って、デフォルトテーマが味気ないので Azusa 使うことにした。日本語環境でも大体いい感じになって素晴らしい » Azusa 3 - 大体いい感じになる無料Keynote・Googleスライドテンプレート https://t.co/v9M7guCpNw
— toshimaru (@toshimaru_e) December 12, 2023
#phperkaigi で発表する予定の資料チラ見せします! 技術的負債解消に興味ある人は遊びにきてね〜(2024/03/08 10:40〜 Track B)https://t.co/GNBuf3EPzn pic.twitter.com/4mUJXGDWLt
— toshimaru (@toshimaru_e) March 4, 2024
当日
#phperkaigi このあと Track B で発表予定の資料を公開しておきました! // 10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡 / legacy-php-app-migration https://t.co/H6LY27egys
— toshimaru (@toshimaru_e) March 8, 2024
#phperkaigi CLI, golangで作るとシングルバイナリで配布が簡単でいいよね。同じ理由でRustで作るのも便利。
— toshimaru (@toshimaru_e) March 8, 2024
#phperkaigi 発表終えたのでお先に酒クズします。アルコールとおつまみがデプロイされているのありがたし〜🙏
— toshimaru (@toshimaru_e) March 8, 2024
#phperkaigi Rubyコミュニティの人たちがいらっしゃったので、PHPコミュニティでRubyコミュニティの談笑をするなどした
— toshimaru (@toshimaru_e) March 8, 2024
#phperkaigi #d PHPer実行委員, キャラ立ちしている人が多くていい😇
— toshimaru (@toshimaru_e) March 8, 2024
女もすなるネイルといふものを、男もしてみむとてするなり#phperkaigi pic.twitter.com/SWc34e6KTa
— toshimaru (@toshimaru_e) March 8, 2024
🍺のPush通知は最高でした#phperkaigi
— toshimaru (@toshimaru_e) March 8, 2024
#phperkaigi お疲れ様でしたー!普段かかわらないコミュニティの方の話を聞いたり、懇親会でいろいろ話せて良かった〜
— toshimaru (@toshimaru_e) March 9, 2024
道産子だけどしっかり北海道にもITコミュニティが根付いてることが確認できたのは良かった
— toshimaru (@toshimaru_e) March 9, 2024
speakerdeckのTranscript文字化け問題困っていたけどこの方法で治った。ただ Preview App がPostScriptに対応しなくなったので、brewで入るghostscriptが必要 » Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題への対処法 https://t.co/Zv0P5fp5yt
— toshimaru (@toshimaru_e) March 9, 2024
#phperkaigi スピーカーとしてプロの声優さん(小桜エツコさん)のアナウンスとともに登場曲流れて喋り始めるの超新体験で、テンションブチ上がった
— toshimaru (@toshimaru_e) March 10, 2024