設計からパフォーマンス、その他様々な実用的な知見が披露された、「CA.swift #7 」に参加してきました！ #ca_swift

こんぬづは、東京→博多の朝一エクストリーム出社はさすがにもう年齢的にきついなと感じた田中です。

今回は株式会社サイバーエージェントが主催する、iOSエンジニアのための勉強会であるCA.swift #7に参加してきたので、そのレポートをお届けします！

今回は『iOSアプリ設計パターン入門』の著者2名をスピーカーに迎えた特別版とのことです！

『Firebase Dynamic Links 導入事例』行木千春

発表内容メモ

発表資料にまとめられていますので、そちらをご覧ください。

感想

BOOTHでもFirebase Dynamic Linksは利用しているのですが、深く踏み込んだ利用の機会がなかったので、この資料を元にして理解を深めたいと思いました。自分は踏んだことはなかったのですが、罠がいくつかあってその現象と対応についてまとめられているのもありがたかったです。

『iOSアプリ設計パターン入門のReduxの章で紹介したサンプルアプリのコードを解説します！』杉上洋平

[スライドは公開され次第、掲載します]

発表内容メモ

『iOSアプリ設計パターン入門』アーリーアクセス電子版の正式リリース🎉
- 現在はアーリーアクセス購入者に紙版をお届けしているステータス
- 一般販売はその後なので、そのあとくらいになると思います。もう少しお待ちください！
アプリ開発の複雑さを高速道路に例える
- どの道を通ればどこにいけるのかがわからない
- アプリ開発でこんな経験ありませんか？
複雑さの根源は変化と非同期
- データフローを1方向に保つことで解決
- データフローを純粋関数で扱うことで副作用を排除して解決
ActionCreatorとReducerの間にmiddlewareを挟むことでログ収集などができるという紹介
〜サンプルコード解説〜

感想

Reduxの概要自体は知っていたものの、発表を聞いて「複数の同じ画面ではどうActionを扱うべきか、あるいは扱わないべきか」「遠いところにある画面間で共通のActionを扱おうとする場合は、どうやってActionの網羅性を担保するか」などの疑問が湧きました。

懇親会ではこれらの疑問に対して、実際にFOLIOで行なっている解決を聞いたり、その場にいた人でアイデアを出し合ったりしました。非常に有意義で楽しかったです。網羅性の担保のために、Actionを合成する話などが特に興味深かったです。

より理解するには実際に書いてみるほかになさそうだったので、今度個人アプリでReduxを試してみようと思いました。

『なぜうちのチームは開発中のアプリをMVVMからMVCに戻したのか』史翔新

発表内容メモ

トレンドに乗っかりたいという理由でMVVMを選定してしまった
結果として、もろもろの要因でプロジェクトが遅延してしまった...
なんでMVVMを使うんだっけ？を整理した
実はそのプロジェクトにMVVMを選定するのは合っていなかったということがわかった
そのうえ、MVCで叶えられない要件ではなかったため、MVCに変更することが決まった
教訓
- 仕様が完全に決まっていない段階で責務を分割しすぎると、逆に仕様変更に弱い
- 納期との戦いの中では無理な設計を導入する必要はない
- MVCはまだまだ現役！
- 設計に銀の弾丸は無い！

感想

要件に沿わないアーキテクチャ選定をしてしまったという失敗を紹介する発表でした。なかなか具体的なケースで「うまくいかなかったからこうした」話は多くないので、とても良いと思いました。

発表の中では「そのアーキテクチャパターンを牽引する人がいない」という問題が紹介されていましたが、実務の中で使ったことのないパターンを導入するのは個人的にはアリだと考えていて、そのうえで最後まで責任をもってやり通すことで知見につながると思っています。なので「うまくマッチしなかったので最終的にMVCにもっていった」判断など聞いていて改めて素晴らしいと感じています。

『Profiling using signpost』鈴木俊裕

発表内容メモ

Performanceを可視化できるInstrumentsの機能
Signpostを使った個人アプリの計測
- やってみたら同時に50並列のHTTP通信が走っていて驚いた
- 流石にやばいので、直した
- Signpostを使ってみたわかりやすい例
- 直した時のPRがこちら: https://github.com/toshi0383/Bitrise-iOS/pull/51
いざデバッグのときにバグが出なくなってしまうことはよくあるので、常に設定をOnにしておいてよいのではないか
- パフォーマンス測定によるパフォーマンスの低下は気にするほどではない
〜Instrumentsを実際に見せるデモ〜
関連
- Measuring Performance Using Logging - WWDC 2018 - Videos - Apple Developer
- Custom Instrumentsのインストール方法 - Qiita

感想

懇親会で改めて確認したところ、Signpostがパフォーマンスを測る対象は特に限定されておらず、開始と終了が定義できるものであればなんでも計測できるとのことでした。発表の中でも紹介されていた通信部分のパフォーマンスが導入しやすいポイントだなと思いました。

たとえば同時に走る通信は何本あるのか、それぞれがどれくらいのスパンで走るのか...。などを計測して、効率をよくするためにprefetchするように修正するとか、キャッシュを持つように修正して効率をよくするとかの対策を立てやすくなりそうだと考えました。

うちのアプリでもやってみたい👀

あとはデモで見せてもらったのですが、計測が失敗するケースもぼちぼちあるようなので、そこは今後の安定性に期待したいところです。

『LLDB Debugging』横山祥平

発表内容メモ

CLIでLLDBを使う場合は/.lldbinitが読み込まれる
XcodeでLLDBを使う場合は/.lldbinit-xcodeが読み込まれる
expression = exprでもかける
breakpointの詳細設定
- condition: 条件
- action: 任意のアクションを実行
〜LLDBのデモ〜

感想

LLDBは「poは使うぞ！」くらいのノリでしたが、UIの色を変更したりプロパティを更新するなどができるので、UI実装と相性が良さそうということを再確認しました。

UI実装の効率化だと、最近こちら: iOSDC2018でPlayground駆動開発について話してきました – mixi developers – Medium を読んで試したいと考えていたのですが、こちらは責務分けが綺麗に行われている場合でないとすぐにできる方法ではないという話を、先日別の勉強会で記事執筆者本人から聞いたので、今回紹介されていたLLDBによるUI実装と使い分けていけると捗りそうだなと夢見ました。