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

potatotips #48 (iOS/Android開発Tips共有会)
にて発表したスライドです

Transcript

1. iOS なアー キテクチャVIPER のススメ @hirothings
2. 5 分で話すこと 1. なぜプロダクト開発にVIPER を採用したか 2. VIPER とは 3. どうチー ムに共有したか 4. テストについて
3. 自己紹介 @hirothings 新卒でラー メン屋勤務 半年で麺場を任される 1 年でラー メン屋店長 色々 あって現在iOS エンジニア Money Forward, Inc. 所属
4. MVC、MVVM アー キテクチャでアプリを作っ て感じた課題 工夫しないと ルー ティングがない デー タの取得・ 加工だけをする層がない 結果、View のロジックとデー タに関するロジックが混在する 依存性をひとまとめに解決する層がない よって実装が属人化する
5. 新規でプロジェクトを始めるにあたって 先の課題は仕組みで解決したい 初期リリー スに間に合わせるにはそこまで時間がない 前提： デー タバインディングを多用するほどのインタラクティブな アプリではない（ プロパティ監視などの実装で担保できると判断）
6. もう少しかっちりしたアー キテクチャが欲しい スピー ドも担保したい
7. VIPER 出典: https://cheesecakelabs.com/blog/ios‑project‑architecture‑using‑ viper/
8. VIPER とは 単一責任の原則をもとに作られたアー キテクチャ 各レイヤー はInterface(Protocol) にのみ依存している iOS の現場で生まれたアー キテクチャ "VIPER is an application of Clean Architecture to iOS apps." 出典: https://www.objc.io/issues/13‑architecture/viper/
9. VIPER のレイヤー View Interactor Presenter Entity Router 各レイヤー の頭文字の組み合わせで VIPER
10. 各レイヤー の説明 Entity バリュー オブジェクト
11. 各レイヤー の説明 Interactor Presenter のイベントに応じてユー スケー スごとにデー タの取得、 加 工をする層 バリュー オブジェクト(Entity) を操作するビジネスロジックが含まれ る View からは完全に分離している
12. 各レイヤー の説明 Presenter View に対するビジネスロジックを持つ層 View とRouter, Interactor の橋渡し的存在 View から受け取ったイベントをもとにInteractor にデー タを要求す る View から受け取ったイベントをもとにRouter に画面遷移を依頼する Interactor から受け取ったデー タをView に渡す
13. 各レイヤー の説明 View Presenter の言われたとおりに画面にデー タを表示する Presenter にユー ザー のイベントを通知する
14. 各レイヤー の説明 Router 画面遷移を管理する 各レイヤー のインスタンスを生成し、 画面を描画する( 依存性をひと まとめに解決する層はここ)
15. ※ 各レイヤー はInterface で繋がっていて、 別のレイヤー の具体的な 実装は知らない
16. 今までの設計に抱いた課題 VIPER を採用すると ルー ティングがない Router が担保してくれる View のロジックとデー タに 関するロジックが混在 Presenter, Interactor で明確に分離され ている 依存性をひとまとめに解決 する層がない Router がインスタンスを生成し依存性 をまとめる役割を担っている 属人化する レイヤー が明確なため属人化しづらい
17. 求めていたものが揃っている感☺ iOS の現場で生まれたアー キテクチャだからか あ、 なんかしっくりくると思った
18. チー ムに共有したい..
19. サンプルアプリを作った よさそう → 自信を持って勧められる状態にするため シンプルなアプリで実装の流れをチー ムに知ってもらう
20. TL が見られる簡単なTwitter クライアント
21. 実装内容 ログイン状態に応じたルー ティング 追加ロー ディング エラー 処理 単体テスト コー ドジェネレー タ 結果: 自信を持って勧めたいと思った。 チー ムでも好評だった
22. 各レイヤー はInterface で繋がっていて、 実態が何をやっているかは知らない = テストが簡単
23. テスト Stub とSpy を使ったユニットテストを採用 入力 ( デー タ取得) Protocol を使ってスタブに差し替える 出力 (View) Protocol を使ってスパイに差し替える メリット テストしたいこと以外のレイヤー をダミー にすることでテスト したいレイヤー 以外の実装に振り回されずに済む 参考： Speaker Deck: 単体テストのハジメ @yokoyas000
24. 例) タイムライン表示のPresenter のテスト
25. 手順1. モックを作る テストケー スごとのダミー デー タを用意する
26. 手順2. モックを入力するスタブを作る Interactor の代わりに、 指定されたモックを返すだけのスタブを作成
27. 手順3. 結果を出力するスパイを作る View の代わりに、 Presenter の結果を出力するだけのスパイを作成
28. 手順4. Presenter のテストを書く
29. VIPER x UnitTest 各レイヤー がInterface だけで繋がっているため簡単にダミー に差し 替えられた Presenter 以外のレイヤー の実装に悩まされず済んだ (View 層のUIKit のライフサイクルなど) 単一責任なためレイヤー ごとのテストもしやすい
30. レイヤー が多い= ボイラー プレー トが多い問題 Kuri などのコー ドジェネレー タを使って解決 https://github.com/bannzai/Kuri テンプレを用意したら画面ごとに必要なファイルを吐き出してくれ る
31. VIPER で実装してみた感想 どのレイヤー が何をすべきか理解しやすい 欲しいレイヤー が揃っていてiOS 開発してて、 しっくりくる Interface で各レイヤー が依存しているため簡単にモックに差し替え られる UI ロジックとビジネスロジックが分離しているのでテストがし やすい
32. まとめ 前提： 現場によって必要なアー キテクチャは違う ただiOS やってる人には誰にもわかりやすく 取り入れやすいアー キテクチャだと思った
33. サンプルアプリを公開しました https://github.com/hirothings/VIPERTwitterClient
34. 参考記事 iOS Project Architecture: Using VIPER Architecting iOS Apps with VIPER
35. ご静聴ありがとうございました