iOSDC Japan 2023 に参加してきた
こんにちは、
9月1日 ~ 9月3日に開催された iOSDC Japan 2023（以下、iOSDC）に参加しました。
僕は、実務で iOS アプリ開発を行うために、最近 Swift を触り始めました。
そのため、iOSDC 参加時点での Swift を用いた iOS アプリ開発経験は、2ヶ月ほどでした。
Swift を用いた iOS アプリ開発経験の浅い僕ですが、iOSDC では有意義な時間を過ごすことができました。
これから Swift を用いた iOS アプリ開発を行っていく僕の視点で iOSDC を振り返ります。
得られたもの
Swift を用いた iOS アプリ開発経験の浅い僕にとって、発表内容を理解することは困難でした。
そんな僕にとって、iOSDC での発表は、以下の2つに分類できました。
- iOS アプリ開発に限定されないプログラミング全般に関する発表
- 今後、利用するであろう技術・知識に出会える発表
iOSDC での発表は、SwiftUI などの iOS アプリ開発に関わる技術についてだけではありません。
今回、僕が聴いた発表の中には、「複雑さに立ち向かうためのコードリーディング入門」や「小さなバグが生んだ悲劇、そこから学ぶ耐障害性の高いアプリ設計」といった、Swift や iOSアプリ開発 に関する知識を必要としないものもありました。
上記のような発表では、使用言語に囚われない開発時の知見を得ることができました。
一方、「StoreKit testingを使ってアプリ内課金のテストや検証を効率化する方法」や「ActorでCoreDataをスレッドから解放しよう」といった発表は、Swift や iOS アプリ開発に関する発表です。
これらの発表では、発表内容を理解し、新しい発見を得るということはできません。
しかし、今後 Swift を用いた iOS アプリ開発を行っていく上で、必要になる可能性がある技術や知識を予め知っておくための機会になります。
例えば、将来、アプリ内課金のテストを行う場合、「StoreKit testing という手法があったな」と思い出すことができたり、CoreDataを用いて開発を行う場合に、「iOSDC で CoreData についての発表があったから見てみよう」というように、その技術を利用する機会が来た際に、その技術についての理解を深めるためのヒントにたどり着くことができると思います。
トークメモ
以下、iOSDC で聴いたいくつかの発表についてのメモです。
小さなバグが生んだ悲劇、そこから学ぶ耐障害性の高いアプリ設計
タクシーアプリ GO で実際に起きた障害事例をもとに、障害が起きた場合の対処方法と、同じ障害を起こさないための対策についての発表です。
アプリ起動時に通常の数百倍のリクエストが送られてしまい、正常にサービスを提供できなくなってしまったというのが実際に発生した障害。
サービスを正常に提供できないため、アプリをメンテナンスモードに変更したいが、アプリ側でメンテナンスモードに切り替えることができず、ユーザを混乱（障害なのか、一時的に重い状態なのか、などの判断をユーザができない）させてしまった。
メンテナンスモードに切り替わらなかった原因は、メンテナンスモードかどうかの情報を API 経由で取得する設計だったため、障害により GO のサーバや DB に負荷がかかり、API レスポンスが返ってこなかったというもの。
対策として、サーバや DB に依存しない場所で、メンテナンス状態を管理する。具体的には、GO の場合、GCS に JSON ファイルを配置し、メンテナンス状態かどうかを Bool 値で管理している。iOS / Android について別々のファイルで管理することで、どちらか一方のみで障害が発生した場合にも対応できるようにする。
複雑さに立ち向かうためのコードリーディング入門
認知プロセスの観点から、複雑なコードを読むときの考え方やテクニックを紹介。
コードリーディング時の複雑さは、知識不足による複雑さ、情報不足による複雑さ、脳の処理能力不足からくる複雑さの3つに分類される。
認知プロセスは、短期記憶、ワーキングメモリ、長期記憶の3つに分類され、それぞれ、情報不足、処理能力不足、知識不足と関係する。
3つの認知プロセスは連携しており、認知プロセスのどこかが妨げられると複雑さを感じてしまうため、認知プロセスが妨げられないように各認知プロセスに応じた対策が必要となる。
短期記憶については、短期記憶の容量が限界を超えると認知プロセスが妨げられてしまうため、情報のチャンク化（複数の情報を1つのチャンクとしてグルーピングすること）により対策をする。
情報のチャンク化の方法として、以下の方法がある
- デザインパターン、データ構造
- 改行で分かれたまとまり
ワーキングメモリで情報を処理する際にかかる負荷は、課題内在性負荷（問題本来の難しさによる負荷）、課題外在性負荷（問題と無関係な負荷）、学習関連負荷（長期記憶に情報を保持する際に発生する負荷）に分けられる。この中で、特に課題外在性負荷を減らすことに焦点を当てたい。
認知的リファクタリングにより、課題外在性負荷を減らすことができる。例えば、動作を変えずに自分の読みやすいコードに書き換えるということ。課題内在性負荷については、問題の難しさを分散するということを考える。例えば、ある関数内で変数の変化を追う場合は、変数の変化を状態遷移図にするなど、情報を頭の中から外に出すことで負荷を減らすことができる。
長期記憶については、長期記憶の誤認識により認知プロセスが妨げられる。新しいプロジェクトへの参加や新しいプログラミング言語の学習など、認知負荷が高い場合に誤認識が起こりやすい。
アンラーニングなどで既成概念を上書きすることで対策を行う。コードレビュー、ペアプログラミング、ベアプログラミング、テストなど、他の視点から思い込みを確認することでも対策可能。
終わりに
iOSDC には、今回はじめて参加しましたが、Swift を用いた iOS アプリ開発経験が歴が浅い僕でも、楽しむことができました。
僕もいつか、iOSDC に登壇したいと思いました。
Discussion