【PHP->TS】古くなったサービスの改修を行うテクニック

この記事は？

著者はサーバーサイドTypeScript, Next.jsといったスタンダードな技術を扱う開発側のエンジニアですが、一方で、15年暦のWebサービス改修の経験もあります。言語に関してはPHP(独自フレームワーク)であるものの、こういった既存サービスの改修ではデバッグや既存の仕様調査、チームやメンバーとの調整、確認といったコーディングに留まらない総合的なスキルが大事になってくる印象です。本記事では、コア部分を改修するためのテクニックを記していきます。本記事ではPHP->TypeScriptのリプレースに基づいていますが、技術はなんでも構いません。

言語そのものへの理解を深める

老舗のサービスでは大量のトラフィックを捌けるように、カスタマイズされたキャッシュを仕込んだり、独自FWを使っているケースが多いです。そういった場合、OSSとしてコミットされているフレームワークのソースを読みにいったり、そういった方面での技術理解が難しいため、言語そのものを理解することを重視します。そうすることが一番技術を理解するに手取り早いです。

ログで実際の稼働状況を掴む

バッチなど、サーバーにログが出されている部分から実際の稼働状況を確認します。また、既存システムのパフォーマンスを移行先の技術スタックで実現できるかどうか？にログも合わせて確認するための材料とします。たとえばバッチであれば、性能評価の一つの観点として、動作が担保されていることはもちろん、バッチの実行速度が改修後で担保されているかなどを確認します。

デバッグによって現状を見る

最も重要な部分がデバッグだと著者は考えていて、既存の整備されていないドキュメントを漁ってつまみ食い的に読むより、目の前にあるコードに対してデバッグを繰り返し、コードと自分の思想を同期できるように努めることが近道と考えています。コードを読む⇄デバッグする⇄ログを出す⇄ドキュメントを作るのサイクルを繰り返して自社にナレッジを蓄積させることが重要です。

移行前にはドキュメントを作る

システムの移行前に十分なドキュメントを作る理由は、新規システムへの移植をチームで円滑に行うためと、旧新でシステムリプレースを行ったときに性能比較をすることができ、仮に思わぬ不具合やシステムパフォーマンスの低下があってもすぐに原因を特定できるようにするためです。

まず、インフラに関してはスペックを調べておくことは前提として、
アプリケーション側であれば以下のような内容をドキュメントに残しておくようにします。

・API
システムが立てているAPIを羅列し、
エンドポイントはどうなっているか？
どのようなレスポンスが返ってきているか？
キャッシュなどの機構はどうなっているか？などを確認する。

・View
既存の画面をどの部分のコードが描画しているか？
描画に必要な部分に対して余分なレスポンスをAPIが返したり、無駄がないか？などを確認する。

・Batch
それぞれのバッチの最近での稼働状況(エラーなどになっているものがないか。
大量のデータの処理などでボトルネックになっている部分はないか。(ある場合改善できないか。

・DB
どのDB/テーブルと通信しているのか？
トランザクショナルであるかどうか？/ストアドなど特殊な処理かどうか？

おまけ(テストを書く

今回はリプレース寄りの内容になったため書いていませんが、Laravelなどのフレームワークを使っていてバージョンアップデートを伴うものが多いシステム刷新では、前提としてテストがある上で行っていきます。リプレースであっても、新規で作るシステムにテストを書いていけば、少なくともそちらの安全性は担保されるので、単体テストを中心に積極的にテストは書いていきたいです。

最後に(本記事のまとめ

新規サービスや新規技術での開発を好む人は多い印象ですが、基幹サービスが長年残っている理由を考えると多くの場合、最も利益を稼ぎ出している部分の一つで、企業活動の骨となっている部分であるので、リプレースを行う重要度としては非常に高いです。リプレースを行なってパフォーマンスが上がるのが一番良いですが、何より気をつけないといけないのは、新規リプレースを行なって既存機能を損なったり、大きな不具合を出さないことです。そのような事態に備える命綱として、既存調査をしっかり行いつつドキュメントをしっかり残すことはとても大事な観点です。