DroidKaigi 2021 - Androidアプリの安全なリファクタリングを行うパターン集 / HiroYUKI Seto [JA] を視聴した

視聴元

• 「必ず直せ」じゃない
  • メリデメを考えるべき
  • 環境場面によっても違う
  • スクラッチ・リファクタリングの組み合わせもOK
• リファクタリング失敗を「減らす」ポイントの紹介

さきにまとめ

• ちゃんとテストを書く
• 破壊的変更したらちゃんと検証する

刷新方法の比較

フルスクラッチ：0から作り出す

• 開発速度が出やすい
• 新規バグを仕込む可能性
• 現行仕様の把握ができていないと難しい

リファクタリング：既存コードの書き換え

• 仕様を把握していなくてもできる
• 新規・既存バグに苦しむ可能性
• 既存実装に引っ張られて開発速度低

リファクタリングで起こりがちな問題

とにかく既存動作が壊れる

• こわれないはずの修正で壊れた
• 想定外範囲で壊れた

原因と対策

原因

想定していない破壊的変更

• ライブラリのアップデート：Changelogにない修正
• 他アプリやFrameworkの連携

検証が難しい領域

• ライフサイクル・非同期処理
• 複合的な要因

対策

難しい

• 検証を手厚く？
  • リソースが必要
• 破壊的変更により動作が壊れるので非破壊的変更では動作は変わらない
  • 破壊的変更を検証すれば問題を見つけやすいはず。
  • 内部動作が意図したとおりか
  • 外部動作しようが意図したとおりか

安全なリファクタリング

• 破壊的・非破壊的を明確に
• 修正後の動作を検証できる状態に
  • 可能な限り自動テストで検証
• 破壊的変更した点を検証する
  • 内部動作が意図したものであること
  • 外部動作仕様が同一であること

実際のリファクタリング

• 計画を立てる
  • ステップの分割
• ゴールを決める
• 破壊的変更・非破壊的変更を混ぜない
• 1ステップの破壊的変更を少なくする
  • 検証を簡単にするため

ステップ分割チェックポイント

そのステップによって検証ができるようになるか

• （自動）テストができるようになるか
• 意図した動作をしているかの検証

破壊的変更か、どこが破壊的変更か

• 動作が変わった点があるか

その破壊的変更に検証方法があるか

• 内部動作は変わったが、外部動作仕様はかわっていない
  • 変更前後で動作が同じか検証
• 内部動作も、外部動作仕様はかわっている
  • 意図通り動作することを検証

MVCによるリファクタリングの実例

凄く参考になる。実際にこれを見ながらやってみるのがよさそう。

1. RemoteDataSourceの作成
2. Repository作成
3. ViewModel導入
4. LiveData導入
5. MVVM化
6. Coroutine化