TL;DR
- I/Fや仕様が明確でないものを再現しながら移行するのは大変
- まずは情報を集約し、目指すべき形を見つけること
- 既存の実装やシステムへのリスペクトを忘れずに
はじめに
現職に転職して、昨年の4月からアプリのサーバーサイドの開発を行うようになりました。
昨年の4~9月は主に既存のものの追加改修を、10〜4月はアプリ側も含めたフルリニューアルを、
今年度に入ってからはサーバーサイドのみのリプレースという形で、開発を行ってきています。
昨年度はアプリも含めたフルリプレースだったので、すべてのAPIのI/Fをゼロから定義し、
わかりやすいアーキテクチャで作り直すことができました。
しかし今年度行っているのは、稼働中のものとは別に新しくAPIサーバーを再構築し、
既存のアプリに影響ないようダウンタイム無しで移行を行うという作業です。
これは、昨年度行ったリニューアルとは比でなく難しく、大変な作業だなと感じています。
何が辛いのか、どういう方針で立ち向かっているのかについて書いていきたいと思います。
何が辛いのか
IFが定義されてない
開発当初はただのバックエンドの土管として想定されていたようで、
アプリがバックエンドのAPIのパラメータを組み立て、
バックエンドから返却されたレスポンスをそのままアプリに返すような実装でした。
(サーバー側でパラメータの付与・置換を行ったり、レスポンスを加工しているものも存在しました。)
つまり、サービスで利用するAPIとして、どういったリクエストを受けるべきで、
どういったレスポンスを返すべきなのかという定義を行う層が曖昧となってしまっていました。
仕様があまり明確ではない
なぜ共通の処理をもっているのか、どういう意図でまとめなかったのかなど、
実装の理由が不明で、当時の関係者にヒアリングをして回って、調査する必要がありました。
独自フレームワークを使っている
過去に社内で作られたフレームワークを利用して開発が行われていました。
このフレームワークの利用経験がいくらかあればまだ違ったのですが、
入社以降あまり触ったことがなく、ググってトラブルシュートするなども難しかったです。
最終的に目指すべき形
アプリ向けサーバーの最も考えるべき要件は、アプリの開発しやすさだと考えています。
公開するI/Fは最低限とし、複雑な加工が必要な箇所はサーバーで加工して返却するなど、
利用する際に考えることなく利用でき、本当に必要な箇所に意識を向けてもらえる状態こそが、
あるべき形であると考えています。
整理されたI/F、仕様は追加開発や施策の検討のための思考の余力を残し、
より加速したサービス開発を行うことができるでしょう。
やりきるための進め方
- 一般的なフレームワークに寄せる
幸い、以前の担当者がJerseyで新サーバーを構築し、移植を始めてくれていました。
この資産をベースに、よりシンプルな形で再構築を進めています。 - 必要なIFだけを定義
アプリと旧サーバーのロジックを追いかけ、定義されるべき値を洗い出します。
また、同じような概念はきちんと共通化されたEntityを用いるようにしています。 - 仕様の整理とドキュメント化
現状の仕様があまり明確ではなかったため、まずは情報の整理を進めました。
ヒアリングした仕様をドキュメントやコメントに残し、ロジックをシンプルにして、
正しい状態が何であるかがわかるようにしています。
忘れてはならないこと
ここまで色々書いてきましたが、リプレースに於いて絶対に忘れてはならないことがあります。
それは、既存のものに対してリスペクトを持つことです。
稼働しているものは間違いなく価値を生み出しています。
そこに対しての敬意を忘れてはいけません。
現在の形になっているのはそうせざるを得なかった理由があるはずです。
行うべきはそれらを紐解いて、整理し、より大きな価値を生み出すことです。
どうすることが最も良い状態を生み出せるかを一番に考えて進めましょう。
