フリュー株式会社フリュー株式会社の開発者が技術情報を発信するブログです。2022-09-28フレームワーク移行のための取り組みを紹介しますはじめにこんにちは、ピクトリンク事業部開発部サーバサイド開発課のkitajimaです。弊社サービスピクトリンクは、システム再構築の一環としてフレームワークの移行を続けてきました。本記事では、システム再構築の計画から作業まで、実際に関わっている1メンバー目線で紹介させていただこうと思います。前提ピクトリンクは長年Seasar2(以下S2)という既にEOLを迎えたフレームワークに依存しており、次なるフレームワークの移行先としてSpringを選択しました。依存している箇所は、プレゼンテーション層、サービス層、永続化層と多岐に渡り、脱却の道のりは決して短いとは言えません。今回紹介するのは、その中でもプレゼンテーション層移行の取り組みについてです。MVCに移行していきます。MVCのコントローラクラス(HogeController)に移行していくイメージです。計画マイルストーンまず、クラス単位でタスクを立ててマイルストーンを引きました。チームでのタスク見積もりは後で行うのですが、ここでは知見のあるメンバーにおおよその規模感を考慮して引いてもらいました。他に考慮すべき点として、施策との兼ね合いがあります。いった再構築作業(「技術的負債の返済」とも言われます)は施策の後回しになってしまいがちで、なかなか進捗を生めないのが悩みどころです。いって施策を完全ストップして再構築に時間を充てるわけにはいかず、並行して取り組む必要があります。施策の繁忙期を考えて再構築のタスクを減らしたり、ポイントの小さいタスクに留めたりといった調整をしたため、コンスタントに進捗を生みだせています。見積もり次に各タスクについて、規模感をチームで見積もります。弊チームはプランニングポーカーという手法を用いて、タスクの相対見積もりをしています。「"相対"見積もり」ですから、チームで「2ポイントとは、〇〇という実装を完了させる規模感である」という指標を共通認識として持ちながら見積もっているわけです。同じアクションクラスといっても、0.5ポイントから5ポイントまで、クラスによって規模感はピンキリです。チームで見積もりするので必ずではないのですが、結果的に以下のような見積もりになっていたという印象です。上記に加え、通信キャリアや決済に関わる機能を持ち、どうしてもスマートフォン実機での手動テストが必要なクラス...5pt※"機能テスト"については、移行の例で詳しく説明させていただきます。3ptの例で挙げたように、中には自動化可能にもかかわらず手動で機能テストを実施しているクラスもあります。対象の機能テストの必要性、コストに応じて、「自動化すべきか、手動実施のまま進めるか」といった整合も含めた上で見積もりをしています。システム再構築を通して、本来の目的であるフレームワークの移行のみならず機能テストの自動化率向上も見込めるのです!最終的に見積もりも含めた上期のマイルストーンは以下のようになっています。上述したように施策との兼ね合いや各タスクの規模感を考慮しているため、一定の消化ペースではないことがお分かりいただけるかと思います。全部で39クラスを、上期(3/28~9/23)の期間をかけて完了させていく見込みです。(画像が小さくわかりにくいですが、チケットの左下に青い四角がついたものが「進行中」、赤い四角がついたものは「完了」です。取り組みの内容をイメージしやすいよう、移行作業について簡単に一例を紹介させていただきます。あわせて、実装を変更した箇所のユニットテストも修正します。methods}メソッドレベルviewを返したい場合の汎用的なメソッド移行は以下のようになります。マッピングやリクエストパラメータの指定ができるアノテーションを移行していきます。hogeObject);}設定ファイルの修正ここでは割愛しますが、web.xmlでマッピングの設定を修正し、今回の移行対象のパスが使用するサーブレットをSpring側になるようにします。以下のようなイメージです。機能テストの実施、自動化ここでいう機能テストとは、ユニットテストとは区別した存在です。APIのレスポンスを検証したり、画面遷移の検証をしたりするものを指します。移行対象のクラスに関連する機能テストを実施していきます。ピクトリンクの機能テストには自動テスト(webブラウザを自動操作するツールを使用して検証するもの)、手動テスト(PCや実機でブラウザを操作して検証するもの)が混在しています。自動テストと違い、手動テストは人間が時間をかけて実施しなければならないのでとにかく大変です。手動テストを減らすため、可能な限りこのフェーズで自動化します。リリース移行したクラスを本番系にリリースします。これで移行完了です!弊チームでは、いくつかのクラスをまとめて定期的にリリースするという方針を採りました。上で紹介した移行例は簡単なものですが、中には以下のように困難を極めるクラスもありました。前述した通り、通信キャリアや決済に関わる機能を持っているクラスは必要な手動テストが多く、非常に苦労しました。通信回線による課金遷移の出し分けを行っていたり、通信キャリアが提供する決済サービスでは二段階認証が挟まったりする関係上、スマートフォン実機操作とテーブル検証を行ったり来たりする必要がありました。テストの方針が今とは異なる時代に作られた機能テストが混在していたため、実施が必要な機能テストを洗い出すだけでも一苦労でした。MVCの振る舞いが違うことが原因で、プロダクトコードのロジック部分は変更していないにもかかわらず不具合が発生してしまうこともありました。multipart/form-dataを取得する処理が、Springに置き換えると動かなくなってしまったのです。解決として、従来はHttpServletRequestから直接取得していたデータを、リクエストオブジェクトを作成してMultipartFileにバインドして受け取るようにしました。}}移行作業では気づかなかった上に原因も全然分からず苦戦したのですが、後ほどチームメンバーが究明してくれました。同じような機能が別のクラスにもあり、そちらにも応用できました。チームメンバーに感謝します!🙏おわりにフレームワーク移行は、本来の目的だけではなく色々な恩恵があったと感じました。機能テスト自動化率の向上、不要な機能の削除、リファクタリングなどはもちろん、新しいメンバーが取り組むのにちょうどいい粒度のタスクがあったことも大きかったと思います。私自身、チームにジョインした直後にこの作業に取り組み、ペアでタスクを進めるというスタイルに慣れていったことを覚えています。kitajimaはフレームワーク移行のおかげで仕事に慣れたと言ってもいいのではないでしょうか・・・!執筆時点でプレゼンテーション層の移行はほぼ完了ですが、まだ他の層の移行が残っており、下期に向けて引き続き計画を立てていくフェーズです。この取り組みの経過も、今後紹介できたらと思っております。お読みいただきありがとうございました!参考資料フレームワーク移行の計画が始まった当時、フリュー社員だった方が発表された資料です。ピクトリンク独自の技術的な課題や内容が充実しているため紹介させていただきます。あけましておめでとうございます。参加報告会(非公式)を開催しました!こんにちは。ピクトリンク事業部の角田です。6引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。