フレームワークや言語のアップデートを行うことで設計やロジックの勉強になる

はじめに

業務で定期的に発生する言語やフレームワークのアップデート。 新規開発でないため、特に上昇志向の強い人からは避けられがちな業務の一つかなと思う。

自分が携わったプロジェクトならまだしも、他人が書いたプロジェクト、もしくは他社が作成したプロジェクトのアップデートを行うことも多々ある。 そういうプロジェクトを担当する中で、考えさせられたことや勉強になったことを簡単に書いていこうと思う。

最近、経験したのは php7->8.5, Laravel8->13, cakePHP4->5である。 特にphp7->8.5は他社の案件を引き継ぎ、一般的なフレームワークではなく自社特製フレームワークのようなクリーンアーキテクチャっぽい構造になっていたので、特に難易度が高かった。一方、Laravelのアップデートは簡単なことが多く、新しいバージョンが出た際には出来るだけ早く行っておきたい。cakePHPのアップデートもLaravelに比べると変更の範囲や幅も大きく、PHPではLaravelがデファクトスタンダードになっている理由がよくわかった。

１．セキュリティ

アップデート対応をしていると、単に動くようにするだけでは済まず、今まで見落としていたセキュリティ上の弱さが見えてくることが多い。

例えばフレームワークを上げていくと、csrf、session、cookie、password hash、シリアライズ、依存ライブラリの脆弱性対応のような箇所で、旧バージョンのまま放置されていた実装に気づく。 普段の業務では業務ロジックに意識が向きやすいが、アップデートではこうした土台の差分を真正面から見ることになる。

特に勉強になるのは、なぜその変更が入ったのかを追うと、過去に実際の事故や攻撃パターンが背景にあることが多い点である。 例えば、

• 以前は許されていたが、今は危険とみなされるシリアライズ方法
• 以前は緩かったが、今は厳しくなったcookie属性
• 以前はそのまま使えたが、今はdeprecatedになっている関数や設定

のようなものを見ていくと、「今のフレームワークが厳しい」のではなく、「過去の実装が甘かった」だけだと分かる。

また、依存関係の更新を行う際にはCVEやリリースノートを見ることになるため、ライブラリレベルでどういう脆弱性が起きるのかも学びやすい。 XSSやSQLインジェクションのような有名な話だけでなく、prototype pollution、unsafe deserialization、権限昇格、path traversalのような問題も、実際の修正差分を追うと理解しやすい。

つまり、アップデート作業はセキュリティの勉強としてもかなり優秀である。 セキュリティ専門の仕事でなくても、普段自分が書くコードでどこを雑にすると危ないのかがかなり具体的に見えるようになる。

アップデートしているフレームワークのgithubリポジトリを見に行き、issueやプルリクのやり取りを見ることからも得られるものが多い。修正の中でバグ等を見つけた際にはissueやプルリクを行えたら理想的な形だと思う。

２．設計

個人的にはここが一番勉強になる。

アップデートで詰まる箇所は、言語仕様そのものよりも、そのプロジェクトの設計が変更に耐えられるかであることが多い。 きれいに責務分離されているコードは、境界部分を直せば済む場合が多い。 逆に、コントローラ、サービス、インフラ、ユーティリティが密結合になっていると、1箇所のアップデート差分が思った以上に広がる。特にコントローラーに大半のロジックが密に詰められている場合は多い。

例えば、次のような設計はアップデート時につらい。

• フレームワークのクラスを業務ロジックの深いところで直接newしている
• グローバル関数やstatic呼び出しに強く依存している
• ライブラリの戻り値形式をアプリ全体で生で使っている
• テストが少ない もしくは 無い、変更の安全性を確認しづらい

逆に、アップデートしやすい設計は次のようなものだと感じる。

• 入出力の境界がはっきりしている
• フレームワーク依存をアダプタ層に寄せている
• DTOやinterfaceで依存先を薄く包んでいる
• テストで振る舞いを固定できている

特に他社案件や昔の案件のアップデートをしていると、「なぜここでこんなに直す必要があるのか」が見えてくる。 それは単に古いからではなく、変更しやすさをあまり意識せずに組まれていたからである。

これは逆に言うと、自分が普段設計するときの良い教材にもなる。 将来アップデートされる前提で考えると、

• 特定ライブラリの型を業務ロジックに漏らしすぎない
• フレームワーク依存の処理を閉じ込める
• 廃止されやすいAPIを広範囲で直接使わない
• 置き換えやすい単位で責務を分ける

といった考え方の重要性が腹落ちしやすい。

新規開発だけをしていると、設計の良し悪しは抽象的な議論で終わりやすい。 しかしアップデート作業では、悪い設計は工数増加という形で露骨に返ってくるので分かりやすい。

３．言語・フレームワークの仕様

当たり前だが、アップデートをするには仕様差分を読む必要がある。 この「読む必要がある」というのが案外大きい。

普段はよく使う範囲の機能しか知らなくても業務は進むが、アップデートになるとmigration guide、release note、deprecated一覧、breaking changeを丁寧に見ることになる。 その結果、今まで曖昧に理解していた仕様がかなり整理される。

例えばPHPのアップデートであれば、

• 型変換のwarningやdeprecation
• traitやattributeの細かい挙動
• PDOや内部関数の変更
• ini設定や実行環境差分

LaravelやCakePHPのアップデートであれば、

• middlewareやrequest lifecycleの変更
• validationやsessionの扱い
• ORMやquery builderの挙動差
• event、queue、cacheの周辺仕様

のような、普段よく分からないまま使っていた部分まで確認することになる。

この作業を通すと、「使える」と「理解している」は別だとよく分かる。 今まではコピペや慣習で書いていた部分も、なぜその書き方なのか、代替案は何か、今後も安全に使えるのかを考えるようになる。

また、仕様変更を読むと、言語やフレームワークの思想も見えてくる。 例えば、

• なぜこのAPIは廃止されたのか
• なぜこの設定はデフォルトが変わったのか
• なぜこの処理は今までより厳密になったのか

を追っていくと、保守性、型安全性、セキュリティ、予測可能性をどのように重視しているかが見えて面白い。

単に上げる作業ではなく、言語やフレームワークの作者側の意図を読む作業でもあると思う。

まとめ

アップデート作業は、地味で面倒な仕事と思われがちである。 実際、派手さはないし、楽な作業でもない。

ただ、その分だけ学べることは多い。

• セキュリティ上どこが危ないのか
• 変更しやすい設計とは何か
• 言語やフレームワークの仕様をどこまで理解できているか

が、かなり実務的な形で見えてくる。

新規開発のような華やかさはないが、エンジニアとしての基礎体力はかなり鍛えられる仕事だと思う。 特に、他人が作ったシステムや古い案件のアップデートはしんどいが、その分だけ得るものも大きい。