はじめに
こんにちは、ClassiのiOSアプリエンジニアの@yoko-yanです。
iOSDC2020に参加して、day0からday2までの３日間で、36のセッションを見ましたので、そのセッションを感想ともに、簡単にまとめたいと思います。
Classiは、iOSDC2020のボトルウォータースポンサーとTシャツスポンサーになっています。
以下、個人的によかったセッションを、紹介します。
どちらかというと、自分の業務や、興味の範囲で、役に立ったかという視点ですので、ご了承ください。
この他にも、参加した中で素晴らしいセッションもあり、参加してないセッションについても、興味深いものは多いんですが、一旦、上記の視点と参加したものの中ではという観点でお話させていただきます。
個人的によかったセッション
新規機能開発からモジュール分割を始めてみる by Ryo Izumi
新規機能開発からモジュール分割を始めてみる - Speaker Deck
マルチモジュール化の話
実際に、モジュール（フレームワーク）化の方法を丁寧に解説
注意点や発見したこと、メリデメなどTipsのような感じ
感想
実際に今の業務でもモジュール化した方がいいねという話はあがっているので、それの判断基準になりそうな話が聞けたのでよかった
XcodeGenは、他のセッションでもよく出てくるので、今のうちに導入は前向きに検討し、実際に導入することになったときのために、知識はもっといた方がいいなと思った
エラーアーキテクチャ設計について考える by きちえもん
エラーアーキテクチャ設計について考える/Thinking about error architecture design - Speaker Deck
エラーハンドリングを、iOSで改善した話とAndroidで改善した話
それぞれ別の話で、コードもそれぞれのコードでの紹介
感想
個人的には、1番このセッションが有用だった。今現在、まさにエラーハンドリングのリファクタをしているところなので、いろんなところに共感できつつ、点で学んでいた中途半端な知識が少し、線でつながった感じ
一部、Androidのコードで紹介していたが、分かりづらいということもなく、考え方は共通なので、逆にiOSでも同じロジックでいけそうだなとイメージ出来たのはよかった
メモ
考え方は、共通なので分かりづらいということもなく、とても分かりやすかった
以下、いくつか頭に残っているものを列挙
- Error型を、そのまま使うと、どんなエラーが起こり得るのか分かりづらい
- 結果の型を、任意のエラー型を指定できるように
- 個別のエラーを表現することができるようになった
- 任意のエラー型は、列挙型で起こり得るエラーを記述
- 固有エラーを、共通エラーと同じ上位で処理すると、全てのエラーを考慮しないといけないロジックになってしまう。
- 固有エラーは別の流れにしてViewModelで処理したほうがいい
一石二鳥: マルチモジュール化, ビルド速度快適化 by Saryong Kang
マルチモジュール化のコツとメリデメの話、bazelを用いたビルド最適化の話、テストの目的や考え方・Tipsなどの話
感想
1番、メモを撮った。モジュール編では、別のモジュール化をテーマにしたセッションをより概念的なところからの話のような感じで、モジュール化に対する理解が深まった
ビルド編では、Bazelというビルドツールを知らなかったので、構築が難しいのと、まだXcodeとの相性が悪そうだが、利用できるようになるといろいろなことが出来そう
テスト編では、テストコードを各基準や目的など、よりどんなテストを書けばいいかの理解が深まった
メモ
実践マルチモージュル編
モジュールを分ける基準
・ドメインロジックがグループに分けられる
・スコープがよく定義されている
・複数のアプリで適用可能
・アプリによって活性化される
・既存のモジュールと明確に違う
・長期間担当するチームが存在している
あとから分けるのは難しい
初期段階で分けた方がいい
スピード感と正しさを両立
ドメインごとの分離
各ドメイン３−４つのレイヤーに分離
Binding,Presentation,Data
Presentationレイヤーは、ドメインロジックと分けるメリットはあまりない
Dependency Inversion Principle 依存性逆転の原則
依存性逆転したほうが、分かりやすい
例えば、Repositoryのインターフェースを、プレゼンテーションレイヤーに書く
ビルド編
Bazel
バックエンドからモバイルまで、幅広くビルドができるもの
Skylark Pythonのサブセット
分析段階のビルドは、LinuxでもOK、コンパイルはMacが必要
Bezelがつかわれない理由
最近のXcodeビルドが、そんなに遅くない
リモートビルドの設定の難易度が高い
Xcodeとの相性が超悪い
であれば
CIサーバーに導入を目標にする
podなどは、ビルドに埋め込む
Googleが方向性を変更、Appleは対応しない方針だったが、転換
テスト編
いいテストの条件
実際のアプリに期待している行動と一緒
目的は、行動の変化がない限り、更新しない
テスト作成の原則
テストが失敗したら、アプリも失敗しているのが理想
XCUITestのつらさを乗り越えて、iOSアプリにUITestを導入する by 佐藤剛士
XCUITestのつらさを乗り越えて、iOSアプリにUITestを導入する - Speaker Deck
PageObjectデザインパターンを導入した、UIテストの導入方法を紹介
UIテストを導入する判断基準から、実際にコードを紹介しつつ、実際に導入する手順まで、丁寧に解説
感想
実際に業務でUIテストの導入を検討したが、ログイン画面がWebだったので、うまく要素が取れず断念したが、Ask the Speakerで、まさに聞きたいことを質問してくれた人がいたので、非常に為になった。再度、UIテストの導入に挑戦してみたい
自社でもQAリソースが足りないことが多く、サービスがWebメインなのでアプリの優先度も高くないので、導入を前向きに検討するための情報を得られた
メモ
UIテストのつらさ
UIは変わりゆくもの
UITestを導入した経緯
UITestの対象、新機能？既存機能？
メルペイでは、既存
リグレッションテストは、２週間ごと
既存機能は安定していることが必要
リグレッションテスト300 自動化対象200項目 CIパス項目40
XCUITest入門
AccessibilityIdentifier
クラス名や要素名を組みあわせる命名規則
Page Object Pattern
テストと画面を分ける考え方 Appniumが提唱するパターン
変更容易性向上 UIが変わっても、Page Object を変更するのみ
Ask the Speaker
Q WebでのUIテストどうしてますか？
A メルペイでは、Webはほとんどランディングページしかないので、UIテストは遷移したかどうかくらいしかチェックしてない
Webをテストする際は、waitは、10秒〜30秒かけた方がいい。結構、読み込みに時間がかかる印象
Q パーミッションのテストはどうしてますか？
A パーミッションは、XCUIアプリケーションで取れないので、システムアラート取得するようにしてる。トークでは省いたけどスライドに追加しました。
組織構造の力学を操作して、アプリ開発プロセスを最大化させる by Masato Ishigaki
組織構造の力学を操作して、アプリ開発プロセスを最大化させる / organizational structure to maximize the development process - Speaker Deck
iOSアプリを開発する中で、生産性のバランス可視化したり意思決定プロセスの構築、開発体制の整備などを行って、新規事業開発で、市場投入までの時間を短縮した話
感想
ちょうど、今やってる業務でユーザーストーリーを作成し、その次にどう進めるかというフェーズだったので、非常に興味があり、実際にAsk the Speakerで質問もしてみて、いろいろ参考になった
iOSの話というより、もっと幅広い話になるが、個人的には前職では、そういったプロジェクトに関わることが多く、同じような課題感を持っていたので、過去にうまくいかなかったプロジェクトが、どう進めればよかったのかを改めて振り返ることが出来た
新規開発だと、機能を積み上げるインクリメント型で作りがちだが、ユーザーのストーリーにそったイッテレーティブ型で作るのが重要という話で、頭の中では分かってるが、図にすると非常に分かりやすいと思って、スムーズに理解できた
メモ
リードタイムを最大限短縮する
ユーザーストーリーマッピング
プロダクトバックログ
ナラティブフローに沿って、行ってレーティブに作る
インクリメントでは作らない
カンバンの可視化したほうがいい
WIP制限をかけてたほうがいい
1番大事なのは、生産性の可視化
Ask the Speaker
（ユーザーストーリーを作成したあとの流れについて知りたかったので）質問してみた
Q ストーリーマッピングの中で、実際にUIデザインをする時にどの程度書き起こすのかと、その後の流れで実際に開発に着手するタイミングを教えてください
A ユーザーストーリーマッピングの時点で、がっつりデザインを作っていた。各工程でグラデーションがあって、初期の段階で、デザインも開発も早い段階で着手し、出来るところから初めていく。多少の手戻りはしょうがない。ワイヤーのデザインもガッチリ作っていた。ワイヤーが何のエピックをやっているか、設計のエピックが何をやっているかを、可視化するのが大事
google/mediapipe で始めるARアプリ開発 by noppe
google/mediapipe で始めるARアプリ開発/iOSDC2020 - Speaker Deck
mediapipeで構築したMLパイプライン(Graph)とARKitを連携して、ハンドトラッカーのフレームワークを作り、バーチャルなボタンを作成する話
bezelというビルドツールを使う
Xcodeでもビルドできる「tulsi」というものがある
感想
個人開発で、KinectやLeapMotionを使ったトラッキングのサンプルコードや、AR/VRのサンプルコードで遊んでいた時期がありかつ、iOSのVisionフレームワークも触ってみたことがあったので、非常に興味があるセッションでした
内容的には、バーチャルボタンをクリックするというシンプルなものでしたが、近未来を感じさせるようなものなので、とてもワクワクした
前職で、個人でHTC VIVEとHoloLensを買った強者がいたが、HoloLensはバーチャルボタンをクリックする体験が出来たので、これがモバイルデバイスレベルで出来るようになったのを感じるのは、とても嬉しかった
Ask the Speaker
きつねのanimojiは、プライベートAPIをハックしてだしたらしい
Swiftで分かるSOLID原則 by 川口 航平
SwiftでわかるSOLID原則 iOSDC 2020 - Speaker Deck
SOLID原則とは何かという話から、SOLID原則を意識してソフトウェア開発を行えば，開発者にとって有益という話
感想
開発をしているとバグを埋め込む可能性にびくびくしながら何回も見直すことが多く、変更に強く理解しやすいシステムを作りたいというのは、常にあるので、SOLID原則を分かりやすく解説してくれたのはよかった
原則のいくつかは、見たことあるものだが、十分理解出来てない部分も多かったので、よく理解できた
特に、依存性逆転の原則については、最近、悩んでるところでもあったので、分かりやすく説明してくれたので楽しみながら学べた
メモ
SOLID原則 変更に強く理解しやすいシステム
単一責任原則
したがっていない例
FatVCがよくある例
リスコフの置換原則
依存性逆転の原則
その他の見たセッションで感想
ここに書いてないセッションの感想を、以下のページに分けて、書きましたので、こちらもどうぞ
iOSDC2020のday0に参加したセッションの内容と感想 - Qiita
iOSDC2020のday1に参加したセッションの内容と感想 - Qiita
iOSDC2020のday2に参加したセッションの内容と感想 - Qiita
見てないセッションで気になるもの
GitHub ActionsでiOSアプリをCIする個人的ベストプラクティス by uhooi | トーク | iOSDC Japan 2020 - fortee.jp
今回、２冠を取られた@uhooiさんのセッション
iOSアプリ開発のための"The Composable Architecture"がすごく良いので紹介したい by 今城 善矩 | トーク | iOSDC Japan 2020 - fortee.jp
初めてRxSwiftを学んだときにお世話になったRxSwift研究読本の著者の@yimajoさんのセッション
まとめ
今回の開催はオンラインということで、これまでの雰囲気とどう違うのかは分かりませんが、おかげで、たくさんのセッションを見ることができて、良かったです。
ただ、去年まで沖縄在住だったので、今回、東京に移住してきて、初の参加だったので、個人的にはオフラインで参加してみたかったというお気持ちです。
今回、オンラインで開催して頂いた、おかげで、見れなかったセッションも、じっくりと見ることができます。（1ヶ月間）
ニコニコ動画のプレミアム会員になると、追っかけ再生が出来るみたいなので、月額540円は、安いと思ったので、迷わず課金しました。
初めてのオンラインということで、運営スタッフは、相当大変だったろうなと思います。
運営の皆様もスピーカーの皆様も感謝！
来年は、オンラインとオフラインのハイブリッドで開催して頂けると嬉しいな。。
（ただ、さらに大変なことになるのは、想像できますね。。）