Twitter での6年間 #7

(Twitter での6年間 6 からの続き)

Apple のイベントからしばらくすると、テックリードから提案があった。ぼくがデモ用に作ったライブラリの設計もコードもきれいで見通しがいいので、そのライブラリをアプリ本体に組み込んで、既存のコードを置き換えてはどうかということだった。ぼくはその提案には反対だった。既存のコードによほど大きな設計ミスがない限り、同じ要求を与えれば同じコードができあがる。ぼくの知る限り、既存のコードに大きな設計ミスはなかった。ぼくは、まずゴールとなる新アーキテクチャーを設計し、既存のコードを徐々に置き換えていくことでゴールに近づけていくインクリメンタルアプローチを提案した。既存のプロモートツイート関連のロジックを新しいコードベースに意味もなく移植したりすることで問題を起こしたくなかったのだ。マネージャーや他のエンジニアたちも同意見で、新アーキテクチャプロジェクトをインクリメンタルアプローチではじめることに決まった。

しばらくチーム内で新アーキテクチャについて話し合いがあり、全体の設計がほぼ決まった。方針としては、まずネットワークレイヤーを置き換え、その次にそれに依存する API レイヤーを置き換える。その最後にモデルレイヤーを置き換えるということになった。とりあえずネットワークレイヤーはパフォーマンス関連のチームのエンジニアが組んだいいものがあったので、それを使うことになった。まずはぼくがその上に新 API フレームワークを構築することになった。

大まかな設計としては、まずサービス非依存の汎用 API フレームワークを作り、その上に Twitter 特有の認証や共通パラメータなどをカプセル化した Twitter API フレームワークを作ることにした。それらのフレームワークの設計は順調に進み、デザインレビューを経て、わりとすぐにマージすることができた。その次に、API エンドポイントを定義している既存のコードを、新 API フレームワークを使った、よりクリーンで見通しのいい定義に置き換えていった。それと並行して、既存の API アクセスコードを、新 API フレームワークを使うように書き換えていく。この地道なマイグレーション作業を、ぼくともう1人のエンジニアでやっていった。Twitter for iOS では 200 以上の API を使っていたので、膨大な作業になった。その頃から、どんな変更を加える場合にも新しいコードパスと古いコードパスを両方ともビルドに残し、フィーチャースイッチというサーバ側で設定を変えられる仕組みを使って実行するコードパスを動的に決めて、うまく動いているかログを取って確認することが開発プロセスとして義務付けられていた。したがって、このマイグレーション作業でも新しいコードパスを追加したときに、古いコードパスを残しておいて、フィーチャースイッチで切り替えられるようにしなければいけなかったので、ずいぶん時間がかかることになった。最終的に半年くらいの時間をかけて、新 API フレームワークへの移行は大きな問題もなく完了した。

(Twitter での6年間 8 へ続く)