設計の世代交代を乗り越える、14年続くAndroidアプリの開発戦略
- Shota AraSansan株式会社
- Naoki WakataSansan
長く運用を続けているAndroidアプリでは、設計の導入やリアーキテクチャの歴史がコードベースに積み重なっていくものです。 MVCの時代から始まり、MVPやFluxの興隆、アーキテクチャガイドによるMVVMの推奨など、広く取り入れられる設計思想が切り替わるタイミングは何度もありました。 Eight Androidにもそういった歴史が積み重なっています。 2012年に開発が開始された私たちのアプリは、複数の世代のアーキテクチャが混在するものになっています。(なんと7世代!) アーキテクチャの変更や採用技術の変更によって、ある時は最適な実装だったものが数年後には認知負荷の原因となり、実装を阻害する要因と化すことも珍しいことではありません。 同じような名前、役割を持つクラスでも、世代によって責務や実装方針が微妙に異なっていることがあります。 設計の世代によって責務分割や状態管理が異なっていると、新しいメンバーのキャッチアップや変更時の影響範囲の特定までもが難しくなります。 そういったアプリの機能開発においては、ただ最新の設計を考慮するだけでは不十分なケースが多くあります。 過去の設計との歪みや世代の溝を考慮すること、そして今の実装が将来の認知負荷に繋がりにくいように考慮していくことが必要です。 恒久的に正解となる設計を探るのではなく、設計の世代間の境界を明確にし、リファクタリングに関する運用を整えておくことで、将来負債化しうる部分を局所化することが重要です。 本セッションでは、私たちのアプリで実際に採用されている設計パターンを参照しながら、長期にわたり運用されているアプリで機能開発とリアーキテクチャを並行して進める上で得た知見を共有します。 過去の設計がどのような背景で導入され、どのような点から変更しづらさに繋がったのかを振り返りながら、現在採用されているレイヤー設計、旧設計との境界の設定、モジュール間依存のルール、案件内や日々の運用でのリファクタリングのスコープ設定について紹介します。 このセッションを通して、新しいアーキテクチャの導入時や運用の中で、旧設計と付き合うために決めておくべき境界やルールを考えるための示唆を得ることができれば幸いです。
対象者
- 長く運用されているAndroidアプリの設計・保守に関わるAndroidエンジニア、テックリード、アーキテクト - 複数世代のアーキテクチャや技術スタックが混在するコードベースに課題を感じている方 - 新しい設計を導入したいが既存設計との境界や移行方針に悩んでいる方