Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
iOSなアーキテクチャVIPERのススメ
hirothings
February 22, 2018
Programming
5
2.6k
iOSなアーキテクチャVIPERのススメ
potatotips #48 (iOS/Android開発Tips共有会)
にて発表したスライドです
hirothings
February 22, 2018
Tweet
Share
More Decks by hirothings
See All by hirothings
VIPER with アーキテクチャ選定 実践入門 / VIPER Architecture
hirothings
4
640
実践Dark Mode対応 / Implementing Dark Mode
hirothings
4
130
iOS標準UIワークショップ / iOS Default UI Workshop
hirothings
3
9.4k
Modernizing Your UI for iOS 13
hirothings
1
620
WWDC2019 pre party LT
hirothings
0
1.9k
Swiftへの愛2018
hirothings
1
2.2k
Swift2年生
hirothings
4
31k
Swiftへの愛
hirothings
0
32k
Other Decks in Programming
See All in Programming
シェーダー氷山発掘記
logilabo
0
140
はじめてのプルリク - BLEA 編
watany
0
140
dotdotdot_in_predict_function
bk_18
1
180
engineer
spacemarket
0
460
Value and Record Types
hschwentner
0
540
模組化的Swift架構(二) DDD速成
haifengkao
0
350
Beyond Micro Frontends: Frontend Moduliths for the Enterprise @enterjs2022
manfredsteyer
PRO
0
110
GitHub Actions を導入した経緯
tamago3keran
1
420
A Philosophy of Software Design 後半
yosuke_furukawa
PRO
10
2.6k
I/O Extended 2022 in Android ~ Whats new in Android development tools
pluu
0
520
Mobile Product Engineering
championswimmer
0
290
trocco® の品質を守る、とても普通な取り組み
kekekenta
0
350
Featured
See All Featured
A better future with KSS
kneath
225
15k
KATA
mclloyd
7
8.7k
What’s in a name? Adding method to the madness
productmarketing
11
1.6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
349
27k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
19
1.4k
The Cult of Friendly URLs
andyhume
68
4.8k
Product Roadmaps are Hard
iamctodd
34
6.5k
How GitHub Uses GitHub to Build GitHub
holman
465
280k
The Language of Interfaces
destraynor
148
20k
Three Pipe Problems
jasonvnalue
89
8.7k
Designing Experiences People Love
moore
130
22k
How to train your dragon (web standard)
notwaldorf
58
3.9k
Transcript
iOS なアー キテクチャVIPER のススメ @hirothings
5 分で話すこと 1. なぜプロダクト開発にVIPER を採用したか 2. VIPER とは 3. どうチー
ムに共有したか 4. テストについて
自己紹介 @hirothings 新卒でラー メン屋勤務 半年で麺場を任される 1 年でラー メン屋店長 色々 あって現在iOS
エンジニア Money Forward, Inc. 所属
MVC、MVVM アー キテクチャでアプリを作っ て感じた課題 工夫しないと ルー ティングがない デー タの取得・ 加工だけをする層がない
結果、View のロジックとデー タに関するロジックが混在する 依存性をひとまとめに解決する層がない よって実装が属人化する
新規でプロジェクトを始めるにあたって 先の課題は仕組みで解決したい 初期リリー スに間に合わせるにはそこまで時間がない 前提: デー タバインディングを多用するほどのインタラクティブな アプリではない( プロパティ監視などの実装で担保できると判断)
もう少しかっちりしたアー キテクチャが欲しい スピー ドも担保したい
VIPER 出典: https://cheesecakelabs.com/blog/ios‑project‑architecture‑using‑ viper/
VIPER とは 単一責任の原則をもとに作られたアー キテクチャ 各レイヤー はInterface(Protocol) にのみ依存している iOS の現場で生まれたアー キテクチャ
"VIPER is an application of Clean Architecture to iOS apps." 出典: https://www.objc.io/issues/13‑architecture/viper/
VIPER のレイヤー View Interactor Presenter Entity Router 各レイヤー の頭文字の組み合わせで VIPER
各レイヤー の説明 Entity バリュー オブジェクト
各レイヤー の説明 Interactor Presenter のイベントに応じてユー スケー スごとにデー タの取得、 加 工をする層
バリュー オブジェクト(Entity) を操作するビジネスロジックが含まれ る View からは完全に分離している
各レイヤー の説明 Presenter View に対するビジネスロジックを持つ層 View とRouter, Interactor の橋渡し的存在 View
から受け取ったイベントをもとにInteractor にデー タを要求す る View から受け取ったイベントをもとにRouter に画面遷移を依頼する Interactor から受け取ったデー タをView に渡す
各レイヤー の説明 View Presenter の言われたとおりに画面にデー タを表示する Presenter にユー ザー のイベントを通知する
各レイヤー の説明 Router 画面遷移を管理する 各レイヤー のインスタンスを生成し、 画面を描画する( 依存性をひと まとめに解決する層はここ)
※ 各レイヤー はInterface で繋がっていて、 別のレイヤー の具体的な 実装は知らない
今までの設計に抱いた課題 VIPER を採用すると ルー ティングがない Router が担保してくれる View のロジックとデー タに
関するロジックが混在 Presenter, Interactor で明確に分離され ている 依存性をひとまとめに解決 する層がない Router がインスタンスを生成し依存性 をまとめる役割を担っている 属人化する レイヤー が明確なため属人化しづらい
求めていたものが揃っている感☺ iOS の現場で生まれたアー キテクチャだからか あ、 なんかしっくりくると思った
チー ムに共有したい..
サンプルアプリを作った よさそう → 自信を持って勧められる状態にするため シンプルなアプリで実装の流れをチー ムに知ってもらう
TL が見られる簡単なTwitter クライアント
実装内容 ログイン状態に応じたルー ティング 追加ロー ディング エラー 処理 単体テスト コー ドジェネレー
タ 結果: 自信を持って勧めたいと思った。 チー ムでも好評だった
各レイヤー はInterface で繋がっていて、 実態が何をやっているかは知らない = テストが簡単
テスト Stub とSpy を使ったユニットテストを採用 入力 ( デー タ取得) Protocol を使ってスタブに差し替える
出力 (View) Protocol を使ってスパイに差し替える メリット テストしたいこと以外のレイヤー をダミー にすることでテスト したいレイヤー 以外の実装に振り回されずに済む 参考: Speaker Deck: 単体テストのハジメ @yokoyas000
例) タイムライン表示のPresenter のテスト
手順1. モックを作る テストケー スごとのダミー デー タを用意する
手順2. モックを入力するスタブを作る Interactor の代わりに、 指定されたモックを返すだけのスタブを作成
手順3. 結果を出力するスパイを作る View の代わりに、 Presenter の結果を出力するだけのスパイを作成
手順4. Presenter のテストを書く
VIPER x UnitTest 各レイヤー がInterface だけで繋がっているため簡単にダミー に差し 替えられた Presenter 以外のレイヤー
の実装に悩まされず済んだ (View 層のUIKit のライフサイクルなど) 単一責任なためレイヤー ごとのテストもしやすい
レイヤー が多い= ボイラー プレー トが多い問題 Kuri などのコー ドジェネレー タを使って解決 https://github.com/bannzai/Kuri
テンプレを用意したら画面ごとに必要なファイルを吐き出してくれ る
VIPER で実装してみた感想 どのレイヤー が何をすべきか理解しやすい 欲しいレイヤー が揃っていてiOS 開発してて、 しっくりくる Interface で各レイヤー
が依存しているため簡単にモックに差し替え られる UI ロジックとビジネスロジックが分離しているのでテストがし やすい
まとめ 前提: 現場によって必要なアー キテクチャは違う ただiOS やってる人には誰にもわかりやすく 取り入れやすいアー キテクチャだと思った
サンプルアプリを公開しました https://github.com/hirothings/VIPERTwitterClient
参考記事 iOS Project Architecture: Using VIPER Architecting iOS Apps with
VIPER
ご静聴ありがとうございました