iOSアプリ設計ナイト に行ってきました

iOSアプリ設計ナイト

これです。

メモ

以下、メモです。かなりの殴り書きです。


試行錯誤でプロジェクトを進めるために(漸進的成長)

    1. プロジェクトを縦に割る
    2. 依存性注入を楽に
    3. 小さな改善を受け入れやすい
    4. ChangeLogと対応が取りやすい
    5. それぞれに README.md を置くことができる
    1. BLoCパターン
    2. Google I/O で初出
    3. 「腕慣らし」として小さく試せる(便利)
    4. ビジネスロジックとの分離が容易

設計の「選定」

  • ex. API Client
  • 「非機能要件を想像する」
    • 品質レベル
    • 開発期間
  • 設計にベストはないがテクニックはある
    • DDD
      • Repository(永続化)
      • API == Cache == Mock になるのでテストが容易になる
  • 設計の選択肢は勉強により増やせるので増やす

テスタビリティの話

  • テストが大変なのは設計がよろしくなさそう
  • 3つの問題
      1. UIテストは高コストなのを何とかする
      2. Model(内部)をテストしやすくする
      3. 状態を検証しやすく
      4. 反復実行がしやすく
      1. タイムライン制御
      2. 仮想時間を用いる
      1. テスト対象の状況を用意しづらい
      2. 外部APIを利用している場合など
      3. 依存をスタブ

設計の何がつらいか

  • 状態がミュータブルだからつらい
    • 排除できないので局所化する
  • 解決法
    • 既存のパターンをよく知って、適切なものを当てはめて解決する
    • 既存のパターンをよく知って、適切に「逃げて」解決する
  • つまり、既存のパターンをよく知るということに尽きる

感想

全員の方に一貫した主張として、

  • 銀の弾丸はない
  • さまざまな条件を考慮して適切なパターンを選ぶ
  • パターンを選べるようになるためには知識を蓄える必要がある

ということだったかと思います。

今までに参加したことがないテーマだったため、とても新鮮でした。今後も同種のイベントには参加していきたいと考えています。

いつもの

f:id:gregminster:20190115212110j:plain

f:id:gregminster:20190115212251j:plain

Powered by はてなブログ