iOSなアーキテクチャVIPERのススメ

by hirothings

Slide 1

Slide 1 text

iOS なアーキテクチャVIPER のススメ @hirothings

Slide 2

Slide 2 text

5 分で話すこと 1. なぜプロダクト開発にVIPER を採用したか 2. VIPER とは 3. どうチームに共有したか 4. テストについて

Slide 3

Slide 3 text

自己紹介 @hirothings 新卒でラーメン屋勤務半年で麺場を任される 1 年でラーメン屋店長色々あって現在iOS エンジニア Money Forward, Inc. 所属

Slide 4

Slide 4 text

MVC、MVVM アーキテクチャでアプリを作って感じた課題工夫しないとルーティングがないデータの取得・加工だけをする層がない結果、View のロジックとデータに関するロジックが混在する依存性をひとまとめに解決する層がないよって実装が属人化する

Slide 5

Slide 5 text

新規でプロジェクトを始めるにあたって先の課題は仕組みで解決したい初期リリースに間に合わせるにはそこまで時間がない前提：データバインディングを多用するほどのインタラクティブなアプリではない（プロパティ監視などの実装で担保できると判断）

Slide 6

Slide 6 text

もう少しかっちりしたアーキテクチャが欲しいスピードも担保したい

Slide 7

Slide 7 text

VIPER 出典: https://cheesecakelabs.com/blog/ios‑project‑architecture‑using‑ viper/

Slide 8

Slide 8 text

VIPER とは単一責任の原則をもとに作られたアーキテクチャ各レイヤーはInterface(Protocol) にのみ依存している iOS の現場で生まれたアーキテクチャ "VIPER is an application of Clean Architecture to iOS apps." 出典: https://www.objc.io/issues/13‑architecture/viper/

Slide 9

Slide 9 text

VIPER のレイヤー View Interactor Presenter Entity Router 各レイヤーの頭文字の組み合わせで VIPER

Slide 10

Slide 10 text

各レイヤーの説明 Entity バリューオブジェクト

Slide 11

Slide 11 text

各レイヤーの説明 Interactor Presenter のイベントに応じてユースケースごとにデータの取得、加工をする層バリューオブジェクト(Entity) を操作するビジネスロジックが含まれる View からは完全に分離している

Slide 12

Slide 12 text

各レイヤーの説明 Presenter View に対するビジネスロジックを持つ層 View とRouter, Interactor の橋渡し的存在 View から受け取ったイベントをもとにInteractor にデータを要求する View から受け取ったイベントをもとにRouter に画面遷移を依頼する Interactor から受け取ったデータをView に渡す

Slide 13

Slide 13 text

各レイヤーの説明 View Presenter の言われたとおりに画面にデータを表示する Presenter にユーザーのイベントを通知する

Slide 14

Slide 14 text

各レイヤーの説明 Router 画面遷移を管理する各レイヤーのインスタンスを生成し、画面を描画する( 依存性をひとまとめに解決する層はここ)

Slide 15

Slide 15 text

※ 各レイヤーはInterface で繋がっていて、別のレイヤーの具体的な実装は知らない

Slide 16

Slide 16 text

今までの設計に抱いた課題 VIPER を採用するとルーティングがない Router が担保してくれる View のロジックとデータに関するロジックが混在 Presenter, Interactor で明確に分離されている依存性をひとまとめに解決する層がない Router がインスタンスを生成し依存性をまとめる役割を担っている属人化するレイヤーが明確なため属人化しづらい

Slide 17

Slide 17 text

求めていたものが揃っている感☺ iOS の現場で生まれたアーキテクチャだからかあ、なんかしっくりくると思った

Slide 18

Slide 18 text

チームに共有したい..

Slide 19

Slide 19 text

サンプルアプリを作ったよさそう → 自信を持って勧められる状態にするためシンプルなアプリで実装の流れをチームに知ってもらう

Slide 20

Slide 20 text

TL が見られる簡単なTwitter クライアント

Slide 21

Slide 21 text

実装内容ログイン状態に応じたルーティング追加ローディングエラー処理単体テストコードジェネレータ結果: 自信を持って勧めたいと思った。チームでも好評だった

Slide 22

Slide 22 text

各レイヤーはInterface で繋がっていて、実態が何をやっているかは知らない = テストが簡単

Slide 23

Slide 23 text

テスト Stub とSpy を使ったユニットテストを採用入力 ( データ取得) Protocol を使ってスタブに差し替える出力 (View) Protocol を使ってスパイに差し替えるメリットテストしたいこと以外のレイヤーをダミーにすることでテストしたいレイヤー以外の実装に振り回されずに済む参考： Speaker Deck: 単体テストのハジメ @yokoyas000

Slide 24

Slide 24 text

例) タイムライン表示のPresenter のテスト

Slide 25

Slide 25 text

手順1. モックを作るテストケースごとのダミーデータを用意する

Slide 26

Slide 26 text

手順2. モックを入力するスタブを作る Interactor の代わりに、指定されたモックを返すだけのスタブを作成

Slide 27

Slide 27 text

手順3. 結果を出力するスパイを作る View の代わりに、 Presenter の結果を出力するだけのスパイを作成

Slide 28

Slide 28 text

手順4. Presenter のテストを書く

Slide 29

Slide 29 text

VIPER x UnitTest 各レイヤーがInterface だけで繋がっているため簡単にダミーに差し替えられた Presenter 以外のレイヤーの実装に悩まされず済んだ (View 層のUIKit のライフサイクルなど) 単一責任なためレイヤーごとのテストもしやすい

Slide 30

Slide 30 text

レイヤーが多い= ボイラープレートが多い問題 Kuri などのコードジェネレータを使って解決 https://github.com/bannzai/Kuri テンプレを用意したら画面ごとに必要なファイルを吐き出してくれる

Slide 31

Slide 31 text

VIPER で実装してみた感想どのレイヤーが何をすべきか理解しやすい欲しいレイヤーが揃っていてiOS 開発してて、しっくりくる Interface で各レイヤーが依存しているため簡単にモックに差し替えられる UI ロジックとビジネスロジックが分離しているのでテストがしやすい

Slide 32

Slide 32 text

まとめ前提：現場によって必要なアーキテクチャは違うただiOS やってる人には誰にもわかりやすく取り入れやすいアーキテクチャだと思った

Slide 33

Slide 33 text

サンプルアプリを公開しました https://github.com/hirothings/VIPERTwitterClient

Slide 34

Slide 34 text

参考記事 iOS Project Architecture: Using VIPER Architecting iOS Apps with VIPER

Slide 35

Slide 35 text

ご静聴ありがとうございました