Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
iOSなアーキテクチャVIPERのススメ
Search
hirothings
February 22, 2018
Programming
5
3.2k
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
940
実践Dark Mode対応 / Implementing Dark Mode
hirothings
4
170
iOS標準UIワークショップ / iOS Default UI Workshop
hirothings
3
10k
Modernizing Your UI for iOS 13
hirothings
1
1.1k
WWDC2019 pre party LT
hirothings
0
2.3k
Swiftへの愛2018
hirothings
1
2.9k
Swift2年生
hirothings
4
34k
Swiftへの愛
hirothings
0
34k
Other Decks in Programming
See All in Programming
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
8
1.2k
仕様変更に耐えるための"今の"DRY原則を考える
mkmk884
8
2.6k
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
210
Amazon S3 TablesとAmazon S3 Metadataを触ってみた / 20250201-jawsug-tochigi-s3tables-s3metadata
kasacchiful
0
180
Honoをフロントエンドで使う 3つのやり方
yusukebe
7
3.4k
楽しく向き合う例外対応
okutsu
0
540
バックエンドのためのアプリ内課金入門 (サブスク編)
qnighy
8
1.8k
Open source software: how to live long and go far
gaelvaroquaux
0
650
Serverless Rust: Your Low-Risk Entry Point to Rust in Production (and the benefits are huge)
lmammino
1
140
バッチを作らなきゃとなったときに考えること
irof
2
460
Unity Android XR入門
sakutama_11
0
170
お前もAI鬼にならないか?👹Bolt & Cursor & Supabase & Vercelで人間をやめるぞ、ジョジョー!👺
taishiyade
7
4.1k
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
GraphQLとの向き合い方2022年版
quramy
44
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Building Adaptive Systems
keathley
40
2.4k
What's in a price? How to price your products and services
michaelherold
244
12k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
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
ご静聴ありがとうございました