Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
RxSwiftを
“チーム開発に”導⼊する話
⾃⼰紹介
⾼橋 祐記
LINE Fukuoka 株式会社
開発2チーム 所属
YUKI TAKAHASHI
今⽇話すこと
・ RxSwiftをなぜ導⼊したか
・ RxSwiftをチームにどう導⼊したか
・ RxSwiftを適⽤したところ
・ RxSwiftを使った感想
今⽇話さないこと
• RxSwiftとはなにかについて
• RxSwiftのオペレータの説明など
⼀番伝えたいこと
• RxSwiftは素晴らしいライブラリだけど、本当に必要かどうか導⼊す
る前によく考えよう!
• 導⼊するなら、チーム内での理解を⾼めて正しく安全に使おう!
なぜRxSwiftを導⼊したか
なぜRxSwiftを導⼊したか
• 「宣⾔的に書ける〜」とか「状態が〜」とかFRP⼀般の概念的な話は
⾊々あるのですが、iOS開発におけるユースケースレベルでいうと主
に2つ
なぜRxSwiftを導⼊したか
主に2つ
• ⾮同期処理の抽象化⼿段として
• MVVM(データバインディング)の実現⼿段として
なぜRxSwiftを導⼊したか
• いままで別々の⼿法を使って実現していたが、
RxSwiftのObservableと呼ばれる型の⾼い表現⼒によってこれらを
統⼀的に扱える!!というのがモチベーション
なぜRxSwiftを導⼊したか
• いままで別々の⼿法を使って実現していたが、
RxSwiftのObservableと呼ばれる型の⾼い表現⼒によってこれらを
統⼀的に扱える!!というのがモチベーション
• Rx以前はどうやっていたかを通してもう...
Rx以前の⾮同期処理
• iOS標準のGCDやNSOperationQueueなどの⼿法
• コールバックやデリゲート
Rx以前の⾮同期処理 (1)
Rx以前の⾮同期処理 (1)
Rx以前の⾮同期処理 (1)
• シンプルなAPI
• コールバック地獄
• 統⼀されないエラー処理
Rx以前の⾮同期処理 (1)
• Future / Promise 系のライブラリ
・Bolts-Swift
・SwiftTask
・BrightFutures ← 推し
・などなど…
Rx以前の⾮同期処理 (2)
Rx以前の⾮同期処理 (2)
Rx以前の⾮同期処理 (2)
• flatMapのようなAPIでモナディックに合成可能。
コールバック地獄にならない。
• エラーのハンドリング⽅法も統⼀できる
• Futureは1つの計算結果を表す
Rx以前の⾮同期処理 (2)
• シンプルなAPIリクエスト
・1リクエスト : 1レスポンス
・(Request) -> Future<Response, Error>
Future / Promiseでも表現できたもの
• アニメーション
・() -> Future<Void, Error> のように表しておけば、
アニメーションの合成も簡単
Future / Promiseでも表現できたもの
• ユーザーの⼊⼒、UIイベント
• 通知など (NSNotificationCenter, …)
Future / Promiseで表現できなかったもの
• ユーザーの⼊⼒、UIイベント
• 通知など (NSNotificationCenter, …)
Future / Promiseで表現できなかったもの
つまり、Future/Promiseだと
複数の値や結果を扱うことができなかった
Rx以前のMVVM
• Viewの状態をモデル化
・ViewModelの更新をするとViewが更新される
・ViewModelとViewのバインディングをしたい
MVVM
• SwiftBondなどのライブラリ
• シンプルなオブザーバーパターン
• KVO
Rx以前のMVVM(データバインディング)
• 正直あまり困っていることはなかった
• 強いて⾔えば、ユーザーイベント経由で⾮同期処理発⽕、みたいな
ものの制御が少しめんどくさかった
Rx以前のMVVM
RxSwiftを導⼊する
• RxSwiftなら⾮同期処理もMVVMの実現も同じライブラリできる!
!
• UIイベントのような、Futureでは表現しきれなかったものも表現で
きるし、なによりRxCocoaでUIKitへのサポートも⼿厚い
RxSwift
• RxSwiftなら⾮同期処理もMVVMの実現も同じライブラリできる!
!
• UIイベントのような、Futureでは表現しきれなかったものも表現で
きるし、なによりRxCocoaでUIKitへのサポートも⼿厚い
RxSwift
あえて導⼊理...
RxSwiftをチームへ導⼊する
• パラダイムも全然違う
• FRP以前にFPへの理解も必要
• 必要性をわかってもらうのも⼤変
– Delegateじゃなんでダメなんだっけ?
– target / actionじゃなんでダメなんだっけ?
Rxは学習コスト⾼め
• 「難しい」や「普通に書きたい」という声はメンバーから上がって
きた
• もうちょっと導⼊に際して⼯夫すればよかったと反省
Rxは学習コスト⾼め
• やったことは以下くらい
・できるメンバーがまず書いてみて参考にしてもらいつつ、レビュ
ーやペアプログラミングなどでサポート
・ちょうどRxSwift本が出たのでオススメした
• やればよかったこと
・布教活動、勉強会
・Observable...
• 概念的なところ
• 各種オペレーター
• エラーハンドリング
• スレッド
特に難しそうと感じたところ
• Next / Error / Completed
・特にCompletedが⻤⾨
・理解していないと、すぐ動かなくなったりメモリリークしたりす
る
・take(1) 警察
概念的なところ
• Hot / Cold
– shareReplay(1)の必要性など
概念的なところ
• 基本的には公式ドキュメントや内部実装を読んでもらうしかないか
なと思っています。
• あとはコードレビューがんばる
概念的なところ
• flatMap / flatMapFirst / flatMapLatest
・⼀番使うオペレータだけど、⼀番ややこしい(と思う)
• ambなど、マイナー(?)なオペレータもがっつり利⽤
各種オペレーター
• RxMarblesなどのサイト
• 公式ドキュメント
• 実装読む ← オススメ
– もっと⾔えば、実装が読めるようになるためのサポートがある
とよいかも
各種オペレーター
• Errorが流れると川はdisposeされる
• 誰が、どこで、処理すべきか
・基本的にはsubscribeやbindをしているメインの川でエラー処理
する
エラー処理
• catchError / catchErrorJustReturn
• retry / retryWhen
・「subscribeからやり直す」
・retryWhenは個⼈的最難関operator
エラー処理
• これは賛否分かれると思うので個⼈的意⾒にとどめておきますが、ハ
ンドリングすべきエラーはResultやEitherと組み合わせて
Obsevable<Result<T, Error>>としてNextで流す⽅が全体の処理
はシンプルになるかと...
• とにかくエラー処理のルールは明確に決めよう!
• ロジックは関数や別クラスに切り出しつつも、全体の川の組み⽴て
、エラーハンドリング、disposeはViewControllerでやるのがシン
プルでよさそうだと思います
エラー処理
RxSwiftを使ったところ
• APIのリクエストは以下のように表現できる。
– (Request) -> Observable<Response>
RxSwiftでの⾮同期処理
• たとえばRepositoryのようなクラス
• A -> Observable<Model>のように作っておけばAPIから取って来
るのか、Realmから読むのかなどを気にする必要がない
RxSwiftでの⾮同期処理
• ユーザーの⼊⼒イベント
・button.rx.tap
• ViewModel -> View
・viewModel.bind(to: view)
RxSwiftとUI
• Alertや⼊⼒系のViewController
・画⾯を表⽰して、⼊⼒された結果を返す
・今回のアプリでは画⾯遷移を含め A -> Observable<B>の形で
表現
・記述量はとても少なくなる!
• が実装が複雑なのでメンテコスト有...
• TableView / CollectionViewにはRxDataSourcesを活⽤
• Modelの配列 → Cell⽤のViewModelの配列 → RxDataSourcesを使
ってbindする
RxSwiftとUI
• バリデーション
・Input ->Observable<Bool> みたいなイメージ
・複数のチェックを⾛らせる場合もmergeやreduceでいける
RxSwiftとUI
RxSwiftを使った感想
• チームが⾃分⼀⼈だったら絶対に使うくらい素晴らしいライブラリ
• 便利だし、楽に書けることも多いけれど…
• チームに導⼊するハードルはなかなか⾼い
RxSwiftは素晴らしいけれど…
• 便利ではあるし、RxSwiftで統⼀できるというメリットはあるが、な
くてもだいたいのことはできる
• 慣れの問題でもあるが、モナドのための構⽂がないSwiftでは可読性
は下がる
• 正しく安全に使わないとすぐにメモリリークしたり、動かな...
• 最新技術、流⾏技術へのキャッチアップは⼤事だが、「流⾏ってい
るから」みたいな理由で安易に採⽤するべきではない
• 正しく安全に使うための⾼い学習コストを払う価値はあるか?
まず、本当に必要かどうか考える
• 採⽤するなら、「なぜ必要か」「どう使うか」をチームメンバーに
共有しよう!布教活動⼤事
• 正しく安全に使うためには深い理解が必須
RxSwiftを採⽤する場合
Thank you.
Upcoming SlideShare
Loading in …5
×

RxSwiftを“チーム開発に”導入する話

3,251 views

Published on

RxSwiftを“チーム開発に”導入する話/髙橋祐記 (ukitaka)
LINE Developer Meetup in Fukuoka #18
https://line.connpass.com/event/60580/

Published in: Technology
  • Be the first to comment

RxSwiftを“チーム開発に”導入する話

  1. 1. RxSwiftを “チーム開発に”導⼊する話
  2. 2. ⾃⼰紹介 ⾼橋 祐記 LINE Fukuoka 株式会社 開発2チーム 所属 YUKI TAKAHASHI
  3. 3. 今⽇話すこと ・ RxSwiftをなぜ導⼊したか ・ RxSwiftをチームにどう導⼊したか ・ RxSwiftを適⽤したところ ・ RxSwiftを使った感想
  4. 4. 今⽇話さないこと • RxSwiftとはなにかについて • RxSwiftのオペレータの説明など
  5. 5. ⼀番伝えたいこと • RxSwiftは素晴らしいライブラリだけど、本当に必要かどうか導⼊す る前によく考えよう! • 導⼊するなら、チーム内での理解を⾼めて正しく安全に使おう!
  6. 6. なぜRxSwiftを導⼊したか
  7. 7. なぜRxSwiftを導⼊したか • 「宣⾔的に書ける〜」とか「状態が〜」とかFRP⼀般の概念的な話は ⾊々あるのですが、iOS開発におけるユースケースレベルでいうと主 に2つ
  8. 8. なぜRxSwiftを導⼊したか 主に2つ • ⾮同期処理の抽象化⼿段として • MVVM(データバインディング)の実現⼿段として
  9. 9. なぜRxSwiftを導⼊したか • いままで別々の⼿法を使って実現していたが、 RxSwiftのObservableと呼ばれる型の⾼い表現⼒によってこれらを 統⼀的に扱える!!というのがモチベーション
  10. 10. なぜRxSwiftを導⼊したか • いままで別々の⼿法を使って実現していたが、 RxSwiftのObservableと呼ばれる型の⾼い表現⼒によってこれらを 統⼀的に扱える!!というのがモチベーション • Rx以前はどうやっていたかを通してもう少し詳細にみてみる。
  11. 11. Rx以前の⾮同期処理
  12. 12. • iOS標準のGCDやNSOperationQueueなどの⼿法 • コールバックやデリゲート Rx以前の⾮同期処理 (1)
  13. 13. Rx以前の⾮同期処理 (1)
  14. 14. Rx以前の⾮同期処理 (1)
  15. 15. • シンプルなAPI • コールバック地獄 • 統⼀されないエラー処理 Rx以前の⾮同期処理 (1)
  16. 16. • Future / Promise 系のライブラリ ・Bolts-Swift ・SwiftTask ・BrightFutures ← 推し ・などなど… Rx以前の⾮同期処理 (2)
  17. 17. Rx以前の⾮同期処理 (2)
  18. 18. Rx以前の⾮同期処理 (2)
  19. 19. • flatMapのようなAPIでモナディックに合成可能。 コールバック地獄にならない。 • エラーのハンドリング⽅法も統⼀できる • Futureは1つの計算結果を表す Rx以前の⾮同期処理 (2)
  20. 20. • シンプルなAPIリクエスト ・1リクエスト : 1レスポンス ・(Request) -> Future<Response, Error> Future / Promiseでも表現できたもの
  21. 21. • アニメーション ・() -> Future<Void, Error> のように表しておけば、 アニメーションの合成も簡単 Future / Promiseでも表現できたもの
  22. 22. • ユーザーの⼊⼒、UIイベント • 通知など (NSNotificationCenter, …) Future / Promiseで表現できなかったもの
  23. 23. • ユーザーの⼊⼒、UIイベント • 通知など (NSNotificationCenter, …) Future / Promiseで表現できなかったもの つまり、Future/Promiseだと 複数の値や結果を扱うことができなかった
  24. 24. Rx以前のMVVM
  25. 25. • Viewの状態をモデル化 ・ViewModelの更新をするとViewが更新される ・ViewModelとViewのバインディングをしたい MVVM
  26. 26. • SwiftBondなどのライブラリ • シンプルなオブザーバーパターン • KVO Rx以前のMVVM(データバインディング)
  27. 27. • 正直あまり困っていることはなかった • 強いて⾔えば、ユーザーイベント経由で⾮同期処理発⽕、みたいな ものの制御が少しめんどくさかった Rx以前のMVVM
  28. 28. RxSwiftを導⼊する
  29. 29. • RxSwiftなら⾮同期処理もMVVMの実現も同じライブラリできる! ! • UIイベントのような、Futureでは表現しきれなかったものも表現で きるし、なによりRxCocoaでUIKitへのサポートも⼿厚い RxSwift
  30. 30. • RxSwiftなら⾮同期処理もMVVMの実現も同じライブラリできる! ! • UIイベントのような、Futureでは表現しきれなかったものも表現で きるし、なによりRxCocoaでUIKitへのサポートも⼿厚い RxSwift あえて導⼊理由を明⽂化するならこんな感じ
  31. 31. RxSwiftをチームへ導⼊する
  32. 32. • パラダイムも全然違う • FRP以前にFPへの理解も必要 • 必要性をわかってもらうのも⼤変 – Delegateじゃなんでダメなんだっけ? – target / actionじゃなんでダメなんだっけ? Rxは学習コスト⾼め
  33. 33. • 「難しい」や「普通に書きたい」という声はメンバーから上がって きた • もうちょっと導⼊に際して⼯夫すればよかったと反省 Rxは学習コスト⾼め
  34. 34. • やったことは以下くらい ・できるメンバーがまず書いてみて参考にしてもらいつつ、レビュ ーやペアプログラミングなどでサポート ・ちょうどRxSwift本が出たのでオススメした • やればよかったこと ・布教活動、勉強会 ・Observableを⾃作してみてもらう ← オススメ Rxは学習コスト⾼め
  35. 35. • 概念的なところ • 各種オペレーター • エラーハンドリング • スレッド 特に難しそうと感じたところ
  36. 36. • Next / Error / Completed ・特にCompletedが⻤⾨ ・理解していないと、すぐ動かなくなったりメモリリークしたりす る ・take(1) 警察 概念的なところ
  37. 37. • Hot / Cold – shareReplay(1)の必要性など 概念的なところ
  38. 38. • 基本的には公式ドキュメントや内部実装を読んでもらうしかないか なと思っています。 • あとはコードレビューがんばる 概念的なところ
  39. 39. • flatMap / flatMapFirst / flatMapLatest ・⼀番使うオペレータだけど、⼀番ややこしい(と思う) • ambなど、マイナー(?)なオペレータもがっつり利⽤ 各種オペレーター
  40. 40. • RxMarblesなどのサイト • 公式ドキュメント • 実装読む ← オススメ – もっと⾔えば、実装が読めるようになるためのサポートがある とよいかも 各種オペレーター
  41. 41. • Errorが流れると川はdisposeされる • 誰が、どこで、処理すべきか ・基本的にはsubscribeやbindをしているメインの川でエラー処理 する エラー処理
  42. 42. • catchError / catchErrorJustReturn • retry / retryWhen ・「subscribeからやり直す」 ・retryWhenは個⼈的最難関operator エラー処理
  43. 43. • これは賛否分かれると思うので個⼈的意⾒にとどめておきますが、ハ ンドリングすべきエラーはResultやEitherと組み合わせて Obsevable<Result<T, Error>>としてNextで流す⽅が全体の処理 はシンプルになるかと思います。 • RxのExampleでもそうしているところがあります。 エラー処理
  44. 44. • とにかくエラー処理のルールは明確に決めよう! • ロジックは関数や別クラスに切り出しつつも、全体の川の組み⽴て 、エラーハンドリング、disposeはViewControllerでやるのがシン プルでよさそうだと思います エラー処理
  45. 45. RxSwiftを使ったところ
  46. 46. • APIのリクエストは以下のように表現できる。 – (Request) -> Observable<Response> RxSwiftでの⾮同期処理
  47. 47. • たとえばRepositoryのようなクラス • A -> Observable<Model>のように作っておけばAPIから取って来 るのか、Realmから読むのかなどを気にする必要がない RxSwiftでの⾮同期処理
  48. 48. • ユーザーの⼊⼒イベント ・button.rx.tap • ViewModel -> View ・viewModel.bind(to: view) RxSwiftとUI
  49. 49. • Alertや⼊⼒系のViewController ・画⾯を表⽰して、⼊⼒された結果を返す ・今回のアプリでは画⾯遷移を含め A -> Observable<B>の形で 表現 ・記述量はとても少なくなる! • が実装が複雑なのでメンテコスト有 RxSwiftとUI
  50. 50. • TableView / CollectionViewにはRxDataSourcesを活⽤ • Modelの配列 → Cell⽤のViewModelの配列 → RxDataSourcesを使 ってbindする RxSwiftとUI
  51. 51. • バリデーション ・Input ->Observable<Bool> みたいなイメージ ・複数のチェックを⾛らせる場合もmergeやreduceでいける RxSwiftとUI
  52. 52. RxSwiftを使った感想
  53. 53. • チームが⾃分⼀⼈だったら絶対に使うくらい素晴らしいライブラリ • 便利だし、楽に書けることも多いけれど… • チームに導⼊するハードルはなかなか⾼い RxSwiftは素晴らしいけれど…
  54. 54. • 便利ではあるし、RxSwiftで統⼀できるというメリットはあるが、な くてもだいたいのことはできる • 慣れの問題でもあるが、モナドのための構⽂がないSwiftでは可読性 は下がる • 正しく安全に使わないとすぐにメモリリークしたり、動かなくなった りする まず、本当に必要かどうか考える
  55. 55. • 最新技術、流⾏技術へのキャッチアップは⼤事だが、「流⾏ってい るから」みたいな理由で安易に採⽤するべきではない • 正しく安全に使うための⾼い学習コストを払う価値はあるか? まず、本当に必要かどうか考える
  56. 56. • 採⽤するなら、「なぜ必要か」「どう使うか」をチームメンバーに 共有しよう!布教活動⼤事 • 正しく安全に使うためには深い理解が必須 RxSwiftを採⽤する場合
  57. 57. Thank you.

×