公開日

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つの移植方針

  1. ロジックKeep移植: Legacy App のロジックを維持したまま移植。
  2. 仕様Keep移植: Legacy App の仕様を維持したまま移植。
  3. リニューアル: 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ポスト

準備編

当日