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

Slide 1

Slide 1 text

クリーンアーキテクチャ脱却と Swift UI導入までの道のり野瀬田　裕樹

Slide 2

Slide 2 text

Speaker - 野瀬田　裕樹（ノセダ　ユウキ） - iOS/Android Engineer - 経歴 - 2013年4月ローム株式会社入社 - 2015年10月株式会社ナビタイムジャパン入社 - 2017年12月ヤフー株式会社入社 - 2019年11月株式会社ディー・エヌ・エー入社

Slide 3

Slide 3 text

サービス紹介

Slide 4

Slide 4 text

- 保険契約者向けの健康増進サービス - 楽しみながら、健康に。 - 2019年6月に公開 - プロダクトは若いが、中身は若くない kencom×ほけん

Slide 5

Slide 5 text

- 健康保険組合などのユーザ向けのサービス - アプリ機能的にはほぼ同じ - これをforkして開発前身：kencom

Slide 6

Slide 6 text

プロダクトの構成

Slide 7

Slide 7 text

全体の構成 Native (iOS/Android) WebView Native BFF WebView BFF マイクロサービスマイクロサービスマイクロサービスマイクロサービス RESTful API internet

Slide 8

Slide 8 text

- 5タブ構成 - ホーム：健康に関する記事の表示 - カラダ：歩数や体重などのデータの管理 - ポイント：ポイントの消費、確認 - お知らせ：サービス側からのお知らせの表示 - メニュー：その他の機能や設定などアプリの構成

Slide 9

Slide 9 text

アプリの構成

Slide 10

Slide 10 text

- アプリ側の主な実装内容 - 画面の状態管理、画面遷移、アニメーションなど - その他はHealthKitとの連携、Push通知など - 複雑なロジックはアプリ内で持っていないアプリの構成

Slide 11

Slide 11 text

- kencomから設計（と技術負債）を引継ぎ - MVP, MVVM, Clean Architectureなどの混在設計 - 問題点 - PresenterやViewModelなどがあり表示ロジックがカオス - 複雑なロジックがない画面での複雑すぎる設計 - kencomとの仕様差分で不要になったコードやリソースの山開発初期のアーキテクチャ

Slide 12

Slide 12 text

どのように問題を解決したか

Slide 13

Slide 13 text

- 現状把握 - 改善の方針決定 - 改善の実施問題解決のアプローチ

Slide 14

Slide 14 text

- より良い実装を考える上で必要な観点 - 現状のコードがどうなっているか - アプリがどのように変化するか - 開発の体制はどうなっているか現状把握

Slide 15

Slide 15 text

- 現状のコード - kencomから引き継いだ技術的な負債 - カオスで複雑な混在設計 - Deployment Targetが不必要に低いまま - 2020年9月時点ではまだiOS10をサポートしていた - （このままではSwift UI導入などは到底できない）現状把握

Slide 16

Slide 16 text

- 現状のコード - kencom×ほけんアプリの変化 - 主にUI面での追加や修正がほとんど - PresenterやViewModelに相当する領域が肥大化しがち - 必要になったらリリース（不定期なリリースサイクル）現状把握

Slide 17

Slide 17 text

- 現状のコード - kencom×ほけんアプリの変化 - 開発体制 - 基本的にはほぼ1人での開発体制 - 既に全体を把握している人はいない - 学習コストが高い複雑な設計を引き継ぐ運用はできない現状把握

Slide 18

Slide 18 text

- プロセスの改善 - 継続的なリリースサイクルの確立 - Deployment Targetの変更ルール確立 - 設計の改善 - 修正が必要な画面ごとに設計と実装を見直し - Cocoa MVCを基本として、画面ごとに最小限の設計に変更改善の方針

Slide 19

Slide 19 text

- ほしい設計の特性 - Swift UIへ移行しやすいこと - UI関連の改修がしやすいこと - 学習コストが低く、引継ぎやすいこと今後の変化を見越した設計

Slide 20

Slide 20 text

- 既存の設計 - Clean Architecture - Swift UI移行やUI改善のしやすさにあまり寄与しない - 学習コストも高く、設計意図の引継ぎが難しい - MVVM - 複雑な画面になるとVMが肥大化しがち - VCとVMの責務がそれぞれ曖昧になりがち - Swift UI移行時にVC/VMの見直しが必要になる今後の変化を見越した設計

Slide 21

Slide 21 text

- 今後の設計 - 単純な画面 - Cocoa MVCを採用 - VCが肥大化しない程度の画面であれば、MVCの方が見通しやすい - 複雑な画面 - StoreパターンやFluxに近い設計を採用 - 画面の状態をState構造体として分離し、Storeに持たせる設計 - Swift UIに移行する際の@Stateに相当するので流用がしやすい今後の変化を見越した設計

Slide 22

Slide 22 text

実際の設計変更の例 - 体重を入力する画面 - 既存実装：MVVM + Clean Architecture - ViewController：200行以上 - ViewModel：100行以上 × 2 - Use Case/Repositoryは単なるAPIのラップ - UI関連の変更は毎回ViewModelとViewControllerを修正していた - 責務が曖昧でVMとVCを都度しっかり読み込む必要があった

Slide 23

Slide 23 text

実際の設計変更の例 - 体重を入力する画面 - 既存実装：MVVM + Clean Architecture - 新規実装：MVC + Storeパターン - ViewController：ほぼViewとStateのbindのみ - UI変更はViewクラス、描画の状態はStateクラスのように責務がわかれて修正がしやすくなった - Stateを切り分けることでSwift UIへの移行がしやすくなった

Slide 24

Slide 24 text

Swift UI移行の実装例：UIKit版

Slide 25

Slide 25 text

- このようにStateを切り出すとSwift UI化が容易 Swift UI移行の実装例：Swift UI版

Slide 26

Slide 26 text

Swift UI時代の設計 View Controller (UIKit) View (Swift UI) Store (Observable Object) - MVC+Storeパターンを採用 - VC：ナビゲーション周りをUIKitで実施 - View：描画全般は可能な限りSwift UIで実装 - Store：各Viewに持たせてobserveする構造

Slide 27

Slide 27 text

Swift UI時代の設計の理由 - MVC+Storeパターンを採用 - Swift UIのナビゲーションで多くの罠があった - Viewに画面遷移を任せたくなかった - UIKitと同じ構造で統一できるようにしたかった View Controller (UIKit) View (Swift UI) Store (Observable Object)

Slide 28

Slide 28 text

- プロダクト状況に合わせた改善を継続 - 設計の改善のためには、プロセスを含めた周辺環境の整備や事前の準備が重要 - Swift UIへの移行の上では、Stateを事前に切り出しておくと便利 - どうしても流用できない箇所や、Swift UI特有の問題もあるため、try&errorを続けているまとめ

Slide 29

Slide 29 text

2021/03/03 Wed @Online 

Slide 30

Slide 30 text

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