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

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

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/

Builders Box

February 15, 2021
Tweet

More Decks by Builders Box

Other Decks in Technology

Transcript

  1. Speaker - 野瀬田 裕樹(ノセダ ユウキ) - iOS/Android Engineer - 経歴 - 2013年4月

    ローム株式会社入社 - 2015年10月 株式会社ナビタイムジャパン入社 - 2017年12月 ヤフー株式会社入社 - 2019年11月 株式会社ディー・エヌ・エー入社
  2. - kencomから設計(と技術負債)を引継ぎ - MVP, MVVM, Clean Architectureなどの混在設計 - 問題点 -

    PresenterやViewModelなどがあり表示ロジックがカオス - 複雑なロジックがない画面での複雑すぎる設計 - kencomとの仕様差分で不要になったコードやリソースの山 開発初期のアーキテクチャ
  3. - 現状のコード - kencomから引き継いだ技術的な負債 - カオスで複雑な混在設計 - Deployment Targetが不必要に低いまま -

    2020年9月時点ではまだiOS10をサポートしていた - (このままではSwift UI導入などは到底できない) 現状把握
  4. - プロセスの改善 - 継続的なリリースサイクルの確立 - Deployment Targetの変更ルール確立 - 設計の改善 -

    修正が必要な画面ごとに設計と実装を見直し - Cocoa MVCを基本として、画面ごとに最小限の設計に変更 改善の方針
  5. - 既存の設計 - Clean Architecture - Swift UI移行やUI改善のしやすさにあまり寄与しない - 学習コストも高く、設計意図の引継ぎが難しい

    - MVVM - 複雑な画面になるとVMが肥大化しがち - VCとVMの責務がそれぞれ曖昧になりがち - Swift UI移行時にVC/VMの見直しが必要になる 今後の変化を見越した設計
  6. - 今後の設計 - 単純な画面 - Cocoa MVCを採用 - VCが肥大化しない程度の画面であれば、MVCの方が見通しやすい -

    複雑な画面 - StoreパターンやFluxに近い設計を採用 - 画面の状態をState構造体として分離し、Storeに持たせる設計 - Swift UIに移行する際の@Stateに相当するので流用がしやすい 今後の変化を見越した設計
  7. 実際の設計変更の例 - 体重を入力する画面 - 既存実装:MVVM + Clean Architecture - ViewController:200行以上

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

    + Storeパターン - ViewController:ほぼViewとStateのbindのみ - UI変更はViewクラス、描画の状態はStateクラスのように責務がわかれ て修正がしやすくなった - Stateを切り分けることでSwift UIへの移行がしやすくなった
  9. Swift UI時代の設計 View Controller (UIKit) View (Swift UI) Store (Observable

    Object) - MVC+Storeパターンを採用 - VC:ナビゲーション周りをUIKitで実施 - View:描画全般は可能な限りSwift UIで実装 - Store:各Viewに持たせてobserveする構造
  10. Swift UI時代の設計の理由 - MVC+Storeパターンを採用 - Swift UIのナビゲーションで多くの罠があった - Viewに画面遷移を任せたくなかった -

    UIKitと同じ構造で統一できるようにしたかった View Controller (UIKit) View (Swift UI) Store (Observable Object)