ジュニアだった頃は、関連する部分をすべて作り直すことがよくあった。 2〜3日ほどほとんど寝ずに作業し、開発サーバーとウェブサイト、モバイルアプリをすべて用意してテストした。デプロイ戦略もテストし、Nginx のプロキシ設定を切り替えて、一度に移行した。 うまく動くと楽しかった。古いコードがなくなり、新しい構造がすぐにサービスに出る感覚もよかった。

しかし、もうそうはしない。互換性を保ちながら、段階的に移行する。 APIを変えるなら、バージョンによってルーティングしたり、一部のリクエストだけに新しいAPIを使わせたりする。UIならフィーチャーフラグを使い、限られたユーザーに向けて新機能を公開する。

サービス全体を移行するときや、新しいフレームワークを導入するときも同じだ。 新しいシステムを作り、既存のシステムをなくしたバージョンをデプロイするよりも、両方のバージョンが動く状態を作って、機能を少しずつ移していく。旧バージョンと新バージョンを一定期間並行して維持する。

大きな切り替えに対するドーパミンは薄れ、仕事は日常的な改善作業になる。

この変化は、ジュニアと一緒に働くようになって生まれた。 チームのジュニアがレガシーを改善することに情熱を感じているのを見るのは、私にとってもとても嬉しいことで、応援したくなることだった。

しかし、新しいチームに加わったとき、そこではジュニアの開発者がすでにUIリニューアルに短くない時間を費やしていて、 チームのマネージャーは新しい機能を追加できないことに不満を感じていた。

私は分かっている。自分が書いたわけではないレガシーコードを保守するのは、そう気持ちのよい作業ではない。 そして、それをひっくり返している間に新機能が出ない期間は、チームを苦しめる。

だから私は、作業を小さく分けることを好むようになった。 2、3か月かけて100を出そうとするのではなく、毎週5ずつ積み上げようと話すようになった。

シニアとして、いつも小さな改善と小さなPRについて話している。 それでも、影響するすべての場所をきれいに一度に変えてしまいたいという欲求は、まだ減っていない。そのほうが楽しいからだ。

だから私は今でも、ジュニアのように作業することが多い。