クリーンアーキテクチャ脱却とSwift UI導入までの道のり@Builders Box 2021.02.09
- 2. Speaker - 野瀬田 裕樹（ノセダ ユウキ） - iOS/Android Engineer - 経歴 - 2013年4月 ローム株式会社入社 - 2015年10月 株式会社ナビタイムジャパン入社 - 2017年12月 ヤフー株式会社入社 - 2019年11月 株式会社ディー・エヌ・エー入社
- 3. サービス紹介
- 4. - 保険契約者向けの健康増進サービス - 楽しみながら、健康に。 - 2019年6月に公開 - プロダクトは若いが、 中身は若くない kencom×ほけん
- 5. - 健康保険組合などのユーザ向けのサービス - アプリ機能的にはほぼ同じ - これをforkして開発 前身：kencom
- 6. プロダクトの構成
- 7. 全体の構成 Native (iOS/Android) WebView Native BFF WebView BFF マイクロサービス マイクロサービス マイクロサービス マイクロサービス RESTful API internet
- 8. - 5タブ構成 - ホーム：健康に関する記事の表示 - カラダ：歩数や体重などのデータの管理 - ポイント：ポイントの消費、確認 - お知らせ：サービス側からのお知らせの表示 - メニュー：その他の機能や設定など アプリの構成
- 9. アプリの構成
- 10. - アプリ側の主な実装内容 - 画面の状態管理、画面遷移、アニメーションなど - その他はHealthKitとの連携、Push通知など - 複雑なロジックはアプリ内で持っていない アプリの構成
- 11. - kencomから設計（と技術負債）を引継ぎ - MVP, MVVM, Clean Architectureなどの混在設計 - 問題点 - PresenterやViewModelなどがあり表示ロジックがカオス - 複雑なロジックがない画面での複雑すぎる設計 - kencomとの仕様差分で不要になったコードやリソースの山 開発初期のアーキテクチャ
- 12. どのように問題を解決したか
- 13. - 現状把握 - 改善の方針決定 - 改善の実施 問題解決のアプローチ
- 14. - より良い実装を考える上で必要な観点 - 現状のコードがどうなっているか - アプリがどのように変化するか - 開発の体制はどうなっているか 現状把握
- 15. - 現状のコード - kencomから引き継いだ技術的な負債 - カオスで複雑な混在設計 - Deployment Targetが不必要に低いまま - 2020年9月時点ではまだiOS10をサポートしていた - （このままではSwift UI導入などは到底できない） 現状把握
- 16. - 現状のコード - kencom×ほけんアプリの変化 - 主にUI面での追加や修正がほとんど - PresenterやViewModelに相当する領域が肥大化しがち - 必要になったらリリース（不定期なリリースサイクル） 現状把握
- 17. - 現状のコード - kencom×ほけんアプリの変化 - 開発体制 - 基本的にはほぼ1人での開発体制 - 既に全体を把握している人はいない - 学習コストが高い複雑な設計を引き継ぐ運用はできない 現状把握
- 18. - プロセスの改善 - 継続的なリリースサイクルの確立 - Deployment Targetの変更ルール確立 - 設計の改善 - 修正が必要な画面ごとに設計と実装を見直し - Cocoa MVCを基本として、画面ごとに最小限の設計に変更 改善の方針
- 19. - ほしい設計の特性 - Swift UIへ移行しやすいこと - UI関連の改修がしやすいこと - 学習コストが低く、引継ぎやすいこと 今後の変化を見越した設計
- 20. - 既存の設計 - Clean Architecture - Swift UI移行やUI改善のしやすさにあまり寄与しない - 学習コストも高く、設計意図の引継ぎが難しい - MVVM - 複雑な画面になるとVMが肥大化しがち - VCとVMの責務がそれぞれ曖昧になりがち - Swift UI移行時にVC/VMの見直しが必要になる 今後の変化を見越した設計
- 21. - 今後の設計 - 単純な画面 - Cocoa MVCを採用 - VCが肥大化しない程度の画面であれば、MVCの方が見通しやすい - 複雑な画面 - StoreパターンやFluxに近い設計を採用 - 画面の状態をState構造体として分離し、Storeに持たせる設計 - Swift UIに移行する際の@Stateに相当するので流用がしやすい 今後の変化を見越した設計
- 22. 実際の設計変更の例 - 体重を入力する画面 - 既存実装：MVVM + Clean Architecture - ViewController：200行以上 - ViewModel：100行以上 × 2 - Use Case/Repositoryは単なるAPIのラップ - UI関連の変更は毎回ViewModelとViewControllerを修正していた - 責務が曖昧でVMとVCを都度しっかり読み込む必要があった
- 23. 実際の設計変更の例 - 体重を入力する画面 - 既存実装：MVVM + Clean Architecture - 新規実装：MVC + Storeパターン - ViewController：ほぼViewとStateのbindのみ - UI変更はViewクラス、描画の状態はStateクラスのように責務がわかれ て修正がしやすくなった - Stateを切り分けることでSwift UIへの移行がしやすくなった
- 25. - このようにStateを切り出すとSwift UI化が容易 Swift UI移行の実装例：Swift UI版
- 26. Swift UI時代の設計 View Controller (UIKit) View (Swift UI) Store (Observable Object) - MVC+Storeパターンを採用 - VC：ナビゲーション周りをUIKitで実施 - View：描画全般は可能な限りSwift UIで実装 - Store：各Viewに持たせてobserveする構造
- 27. Swift UI時代の設計の理由 - MVC+Storeパターンを採用 - Swift UIのナビゲーションで多くの罠があった - Viewに画面遷移を任せたくなかった - UIKitと同じ構造で統一できるようにしたかった View Controller (UIKit) View (Swift UI) Store (Observable Object)
- 28. - プロダクト状況に合わせた改善を継続 - 設計の改善のためには、プロセスを含めた周辺環境 の整備や事前の準備が重要 - Swift UIへの移行の上では、Stateを事前に切り出し ておくと便利 - どうしても流用できない箇所や、Swift UI特有の問題もあるた め、try&errorを続けている まとめ
- 29. ご清聴ありがとうございました
- 30. for Q&A
- 33. Q. AndroidのアーキテクチャもiOSで採用されているFluxで構成しているのでしょうか？小規 模なチーム開発する場合、AndroidとiOSで似たアーキテクチャの方がお互いキャッチアップ しやすいのかな？と思っているのですが、その点ご意見いただければ嬉しいです。 A. いえ、Androidは基本をMVVMにして、Repositoryを用意するような設計になっています。 Androidの設計にあたってはGoogle推奨の設計ドキュメントが公開されていることもあり、そ れに則って設計・実装する方がキャッチアップやAndroidのアップデートへの追従がしやすい などのメリットがあると考えています。AndroidとiOSでは表示に関する要素、設計が全く異な り、例えばAndroidであればxmlとActivity/Fragment+ViewModelで表示周りを実装します が、iOSであればSwift UI Viewやstoryboard/xibとUIViewController/UIViewで表示周りを実 装するというように、かなりFrameworkに依存する部分なので、共通化が難しいというのもあ ります。互いにキャッチアップするという観点でいうと、同一機能のクラスの命名を揃えておく とか、UIからは分離されたモデルクラスをほとんど共通のものを使うとか、Swaggerなどで APIをドキュメントから生成するという形を取る方が望ましいと思われます。