Slackは、iOSアプリとAndroidアプリを最新の状態にし、新しいデザイントレンドを採用することに成功した。これによって、特にSwift for iOSへの完全な切り替えができるようになった。
SlackのエンジニアがiOSアプリとAndroidアプリを刷新することを決定したとき、開始から数年経つ2つのコードベースの現実に直面しなければならなかった。そのコードベースは有機的に成長し、時間の経過とともにかなりの技術的負債を蓄積してきた。完全な書き直しとプラットフォーム間でのコードの再利用のアイデアを捨てた後、完全なリファクタリングをすることに決定した。
このオプションを選択するということは、既存の技術的負債に対処する必要があることを意味します。私たちはレガシーコードを移行し、アプリを適切な場所に再構築する必要がありました。それと共にアプリを出荷可能な状態に保ち、新機能の開発を継続する必要がありました。
その結果を達成するために、チームは3つの異なる目標を立てた。それは、技術的負債を取り除くためにコードベースを安定させること、アプリを個別のコンポーネントにモジュール化すること、設計と技術スタックの取り組みをモダン化することである。
安定化が最初にできるステップであった。例えば、iOSでは、Objective-Cでまだ書かれているアプリの残りの部分をSwiftで書き直した。Slackのエンジニアによると、同じプロジェクトにSwiftとObjective-Cコードが共存すると、コンパイルが遅くなり、パフォーマンスに影響が出る。しかし、相互運用性の要件により、新しいSwift言語機能の採用が妨げられていた。
さらに、Core Dataに直接アクセスするコードを書き直して、独自のCore Dataベースの永続フレームワークを使用するようにする必要があった。これにより、パフォーマンスと安定性が向上した。同じように、すべてのネットワーク操作は、内部接続フレームワークを使用するように書き直された。
Androidでは、ほとんどの作業は、ネットワークとデータベースアクセスに使用されるいくつかのモノリスを分割することを目的としていた。後者では、SQLDelightを採用し、既存のすべてのSQLiteクエリを移行している。さらに、Slackチームはリポジトリパターンを採用した。これにより、よりスマートなキャッシングがサポートされ、パフォーマンスの向上が容易になった。
安定化フェーズの重要な要素は、上記の各目標に関連付けられた明確なメトリックを使用して進捗状況を追跡することであった。たとえば、Objective-CからSwiftへの移行を追跡するために、チームはスクリプトを使って残りのObjective-Cファイルの数をカウントした。また、非推奨のクラス名とメソッド名をカウントすることで、目標までの残りを把握する役にたった。
前述のように、モジュール化は、2つの既存のモノリスから多くのコンポーネントを切り出すことを目的としている。この取り組みにより、コードベースとともに大きくなった相互依存性とビルド時間が低減された。しかし、大きく寄与したのは、個別のチームがより独立した方法で作業できるようになったことである。
Slackのエンジニアは、プロジェクトの安定化フェーズについて、ここで要約できるものよりもはるかに多くの背景と詳細を提供している。そのため、全体像の把握のために元の投稿を見逃さないようにしてください。