Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

9c733dc2d65e7dcce91fa62be8bbb2ee?s=47 Builders Box
February 15, 2021

クリーンアーキテクチャ脱却と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/

9c733dc2d65e7dcce91fa62be8bbb2ee?s=128

Builders Box

February 15, 2021
Tweet

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×ほけんチームはどのように立ち向

    かっていったのか、課題解決の施策を中心にお話します。
  31. None
  32. Follow @DeNAxTech ぜひフォローして下さい

  33. ご清聴ありがとうございました