iOSアプリ設計ナイト
これです。
メモ
以下、メモです。かなりの殴り書きです。
試行錯誤でプロジェクトを進めるために(漸進的成長)
- プロジェクトを縦に割る
- 依存性注入を楽に
- 小さな改善を受け入れやすい
- ChangeLogと対応が取りやすい
- それぞれに
README.md
を置くことができる
- BLoCパターン
- Google I/O で初出
- 「腕慣らし」として小さく試せる(便利)
- ビジネスロジックとの分離が容易
設計の「選定」
- ex. API Client
- 「非機能要件を想像する」
- 品質レベル
- 開発期間
- 設計にベストはないがテクニックはある
- DDD
- Repository(永続化)
- API == Cache == Mock になるのでテストが容易になる
- DDD
- 設計の選択肢は勉強により増やせるので増やす
テスタビリティの話
- テストが大変なのは設計がよろしくなさそう
- 3つの問題
- UIテストは高コストなのを何とかする
- Model(内部)をテストしやすくする
- 状態を検証しやすく
- 反復実行がしやすく
- タイムライン制御
- 仮想時間を用いる
- テスト対象の状況を用意しづらい
- 外部APIを利用している場合など
- 依存をスタブ
設計の何がつらいか
- 状態がミュータブルだからつらい
- 排除できないので局所化する
- 解決法
- 既存のパターンをよく知って、適切なものを当てはめて解決する
- 既存のパターンをよく知って、適切に「逃げて」解決する
- つまり、既存のパターンをよく知るということに尽きる
感想
全員の方に一貫した主張として、
- 銀の弾丸はない
- さまざまな条件を考慮して適切なパターンを選ぶ
- パターンを選べるようになるためには知識を蓄える必要がある
ということだったかと思います。
今までに参加したことがないテーマだったため、とても新鮮でした。今後も同種のイベントには参加していきたいと考えています。