DroidKaigi 2022 - 長期運用アプリのリファクタリングを考える | shinmiy [JA] を視聴した

視聴元

アーキテクチャに関する歴史

2016年ごろまで

• アーキテクチャは実装者任せ。
• GoogleはOSの機能開発に徹する。
• それをどう使うかは開発者におまかせ

2017／2018年

• Googleがアーキテクチャの指針を公開
• Kotlinや Kotlin Coroutine が公開

2021年

• より詳細なアーキテクチャガイドの発表
• その大きな変化の中、それを生き延びてきたアプリがある。長期運用されてきたアプリをどうやって適用させていくべきか。

改善の対象となるもの

技術的負債がたまって、今後の対応が難しくなってきたアプリ

• 担当者の変化
• 仕様の変化

その結果生まれるコード

• GodActivity
• マルチアーキテクチャ

それにより

• 機能開発の高難度化
• コードの学習コスト高
• 開発者のモチベーション低下

改修すべきじゃないもの

• アーキテクチャが忠実に守られている
• 仕様が明確で変化が少ない

「今後の変更がしやすいアプリ」を目指すために

アーキテクチャガイド

• ベストプラクティスとして無理がない
• 共通言語ができた
• 関連する知見が共有しやすくなった

JetpackCompose

• 今後はこれに代わる

しかし、一気にやると無理が生じる

• 例えば画面単位／機能単位でやるとよさそう。
• それにあたって大きく3つのフェーズがある。
• 理解・整理フェーズ
• 分離フェーズ
• 置き換えフェーズ

理解・整理フェーズ

元のコードに対する理解・整理。3回のリファクタリングを経て実施。

1回目：理解のためのリファクタリング

• ASの力をふんだんに使う
• 理解が進んだら、全部飛ばす

2回目：整理のためのリファクタリング

• やることは1回目と似ているが理解を前提として

3回目：コミットのため

• 丁寧にコミットするためのリファクタリング

集中して1回のセッションで終わらせる（短期集中）

• あとで「何やってたんだっけ」
• 熱量の変化（低下）

分離フェーズ

• 関心の分離を意識しつつ、リファクタリングしたコードで分離できるものを分離
• データレイヤから引き離していくと個別にテストしやすい・変更しやすい
  • 例：サーバ通信
  • 例：アプリ内DB
• もしくはフルスクラッチでデータレイヤを追加して徐々にそちらにシフト

置き換えフェーズ

Activityによる画面遷移の場合、JetpackComposeにいきなりシフトするのは難しい

• 段階を踏んで取り入れることで無理なく置き換える
• 極力ペイロードを減らすとあとあと嬉しい

最後に

• 前任者を絶対にディスらない！！！
• 今のコードは価値や利益を生んでいるコード。今のコードとなった背景や起因などがあったはず。