LCL Engineers' Blog

バス比較なび・格安移動・バスとりっぷを運営する LCLの開発者ブログ

iOSDC Japan 2017 day1 レポート

iOS 勉強会レポート

前夜祭を含んだ3日間で開催されるiOSの国内カンファレンス、iOSDCに参加してきました。

今回はその1日目（9/16）のレポートです。

今年のiOSDCは最大4つのメインセッションが並行で行われるということで、

前日から公開されていたタイムテーブルを見ながら、当日参加する予定を立てました。

タイムテーブル | iOSDC Japan 2017

レポート

オープニングは10時でしたが、急遽私用ができてしまい午後からの参加となりました。

ランチ前の時間に到着したのですが、ボランティアスタッフの方々が 終日受付対応をしてくださっていたので、スムーズに入場することができました。

ノベルティ

ノベルティは トートバッグ一杯に入っていました。 チケットのグレードが一段階上の「個人スポンサー」の方には更に扇子、ハンドタオル、 パーカー、チートシート下敷きがあったそうです。

f:id:lcl-engineer:20171031113640j:plain

日常的に使えるグッズばかりで助かります。

ランチ

iOSDCさんのツイート: “【ランチ手順】食べたいサンドイッチを選ぶよ！(3種類！)#iosdc https://t.co/W2abjyyjXJ”

サンドイッチ、サラダ、飲み物がそれぞれ複数種類用意されていました。 自分はタンドリーチキンのサンドとチリコンカンを選びましたが程良いピリ辛感でおいしかったです。

Build high performance and maintainable UI library

13:30~14:00 / Track A / Realm

Building High Performance and Testable UI component // Speaker Deck

要点

  • 高速なUIを作るには「計測」と「トレードオフ」が不可欠
    • 計測
      • 負荷の高い処理を減らす（原因を知る、速度を上げるテクニックを学ぶ）
    • トレードオフ
      • パフォーマンスを上げるに辺り、犠牲は付き物である。伴うトレードオフを知る。
      • 例：パフォーマンスを上げるために、コードが複雑になる
  • メンテナンスしやすい = テストしやすい
    • UIコンポーネントをテストするのは難しい
      • 内部状態が多く複雑 / 状態を変化させる要因が多い / 状態が相互作用を及ぼす / 正しい挙動が明確でない
    • Unit Testing vs UI Testing
      • UIテストはテスト対象に直接アクセスできない
      • 成功・失敗の基準が明確でない
    • テストの段階は大きく4つにわけられる
      • 内部状態、パラメータ、関数、出力結果
      • マッシブなUI（ViewController）は、各段階でイレギュラーで明確でない要素が複雑に絡み合っている
    • テストしやすい構造とは
      • データの流れを1方向にする
      • 状態をモデルに分離する
    • テストしやすい構造にすることで振る舞いをモックに置き換えれる
    • 薄いビュー（コントローラー）、分厚いモデル
  • Q/A
    • View側でイレギュラーなアクションが発生する場合は網羅的なテスト書くことを避けられない（使い分けが必要）

感想

弊社のiOSプロジェクトの「高速バス比較 – 国内の路線と最安値を検索するアプリ」でも 現在、安定性やパフォーマンスの向上を図るためにリファクタリングやUnit Test、UI Testの導入を行っています。

設計から見直したリファクタリングを経て、マッシブなVCから責務を細かく分割することができつつありますが、 テストとの兼ね合いを考えると構造が最適化できていない箇所もあるため、改めて見直したいと思いました。

モバイルアプリで困らないエラーハンドリングとロギングのベストプラクティス

14:20~14:35 / Track C / Mercari

モバイルアプリで困らないエラーハンドリングとロギングのベストプラクティス // Speaker Deck

エラーハンドリング、ロギングのやり方は多くの人が必要としている情報なのか、立ち見が出るほど人が集まっていた

要点

  • Crashlyticsで一番重要なこと
    • ログはクラッシュ後にアプリが再起動した時に送られる
    • application:didFinishLaunchingWithOptionsを無事に通過しないとダメ
  • application:didFinishLaunchingWithOptionsでしそうなこと
    • 各種フレームワークの初期化 / DBのマイグレーション / キャッシュのクリア
      • メインスレッドを長時間止めない
  • Crashlyticsには便利な付加情報がある
    • UserID、Email、名前などが追加可能
    • Key/Valueを追加可能（制限あり）
    • クラッシュしなくてもログを送ることが可能
  • iOS10から使えるようになった OSLog と組み合わせて自作ロガーを作る
    • コードはスライド参照
  • guard文のアンラップ時など、ありえない想定でもログレポートを吐かせるのが大事
    • 例えば、チームメンバーが変更した際など 将来的に発生する可能性もある

感想

標準のレポートに加えてログを渡す方法など参考になりました。

「ありえない想定でもログレポートを吐かせる」 、 これができていなかったので早い段階で各所に対応しようと思います。

短期間でやり遂げるための、大規模リニューアルの進め方

15:10~15:40 / Track A / Retty

短期間でやり遂げるための、 大規模リニューアルの進め方 // Speaker Deck

要点

  • 何故リニューアルをするか
    • 成長 / ピポット / 陳腐化 / リファクタリング / セキュリティ
  • どのようにリニューアルを進めるか
    • 徐々に / 一気に長期間 / 一気に短期間 / プロダクトを分けて
    • 各メリデメはスライドを参照
  • リニューアルあるある
    • 膨らむ仕様 / 足りない人手 / あとで増やされる人手 / 見積もりの不正確さ
      • 1日8時間コードを書けると思っている
      • 見えないタスクがあることを考慮しない
      • 仕様決定が遅れても工数調整しない
  • スコープを明確にする
    • 新規のはできるだけ増やさない
    • やらないを明確に
    • 決める人を明確に
  • Design Doc
    • プロダクト全体の仕様書のようなもの
    • 目次はスライドを参照
    • 今回のリニューアルに向けて、これを作るのに3ヶ月掛かった

感想

リニューアルあるあるについては、普段の業務の中でも気をつけたいことだと思いました。 特に 「1日8時間コードを書けると思っている」 は、普段から気をつけていても ふとした時に上のように単純計算をしてしまい、見積もりが合わないことが自分にもたまにあります。

Design Docについては、今後もし大きめのリニューアル（もしくは新規プロジェクト）に関わる機会があったら 実際に試してみようと思いました。

ディープリンクの設計と実装

16:00~16:30 / Track A / 一休.com（一休レストラン）

ディープリンクの設計と実装 - iOSDC2017 // Speaker Deck

要点

  • どういう用途で使うか
    • Webやメールからアプリ内の特定のページを開く
  • 他社アプリを開くには独自URLスキームをハードコーディングする必要がある
  • iOSでは似たような機能でUniversal Linksがある
    • Googleから開く
  • なぜディープリンクが求められるのか？
    • スライドを参照
  • 実装方法
  • アプリ内URLを設定すると便利なこと
    • PUSH通知からも開ける
    • アプリ内WebViewから開く画面を指定する
  • 悩むこと
    • タブバーを利用している場合どこから開くか
    • モーダルはユーザビリティがあまり良くない
    • ドリルダウンの再現（中間のページを考慮する）
    • 全画面に対応することはない
      • WebページのPVで判断
  • URLスキームの設計方法
    • path = host じゃないか（スライド参照）
  • Universal Linksお悩みポイント
    • Web側のPV計測が狂う
    • Webとアプリのビジュアルの統一性
      • 連続性を感じられるデザインにする
    • サブドメインで発動してしまう
  • Q/A
    • テストはルーターのみ行っている
      • それ以外は手動
  • その他
    • 自由なドリルダウンが発生するのは良くないのでdismissは遷移の事前にやっておいたほうが良さそう

感想

弊社のプロダクトもWebとiOS,Androidでディープリンクを採用可能なページがありますが、 まだアプリに一任するメリットが大きくないと考えているため、採用には至っていません。

しかし、どこかのタイミングで今後採用する可能性は大きくあるので その際はURLスキームの設計方法など活かしたいと思います。

LT

  • 第３の課金形態「寄付モデル」ってどうなの？
    • 寄付モデルにトライ＆エラーした話
    • 当日の最優秀LT賞になっていた
  • 多次元宇宙と画面遷移
    • 宇宙の話からいつの間にか画面遷移について説明
  • iOSで利用できるデバイスファームのメリット・デメリットの紹介
    • デバイスファームの各サービス比較
  • ローカライズの苦しみに立ち向かう
    • デザインの段階で単位の書き方を控える（単数、複数、○位）などなど
  • クラス名に個人の名前を含めるとこうなる
    • 純粋に面白かった（盛り上がっていた）
    • Swiftを書いている内はクラスにプレフィックスを付ける文化には会わなさそう

終わりに

現在直面していることやこれから対応を考えていることについて、 詳しく話を聴くことができたのでとても参考になりました。

会場の環境もWi-Fi環境が用意されていたり、各所で案内板があったりと 快適且つ親切な環境でとても参加しやすかったです。

当日聴けなかったセッションについては、登壇者の方々がSpeaker Deckなどに スライドを公開してくださっているのでBlogやTwitterをチェックしていと思います。