クリーンアーキテクチャ脱却とSwiftUI導入までの道のり / Beyond Clean Architecture and Introducing SwiftUI

■イベント 

【Engineering Team Presentation】各社の事業を支えるアーキテクチャ
https://sansan.connpass.com/event/200589/

■登壇概要
タイトル：クリーンアーキテクチャ脱却とSwiftUI導入までの道のり
発表者：株式会社ディー・エヌ・エー　DeSCヘルスケアシステム部システムソリューショングループ
iOS Engineer　野瀬田 裕樹

▼Builders Box
https://buildersbox-online.com/

Transcript

1. クリーンアーキテクチャ脱却と Swift UI導入までの道のり 野瀬田　裕樹
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への移行がしやすくなった
24. Swift UI移行の実装例：UIKit版
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. 2021/03/03 Wed @Online

30. Monorepo と OneTeam で Microservices の課題に挑む 細分化されすぎたマイクロサービスと呼応して増えるレポジトリ の数、レポジトリ毎に異なる開発スタイル、サーバとインフラ チームのコミュニケーション不足によるオペレーションの分断... これらの課題にkencom×ほけんチームはどのように立ち向 かっていったのか、課題解決の施策を中心にお話します。
32. Follow @DeNAxTech ぜひフォローして下さい
33. ご清聴ありがとうございました