[イベントレポート] 「Build high performance and maintainable UI library」 というセッションを聞いてきました！ #iosdc #a

はじめに

こんぬづは、最近はiOSのプラットフォームを離れたところを仕事でしているのですが、そこで得た経験とiOSDCに来て受けた刺激をうまく組み合わせてなにかやりたい熱が高まっている田中です。

iOSDC 2017に参加しています！ このエントリでは筆者がタイトルのセッションを聞いて 印象に残ったところ と 感想 を書いていきます！

Build high performance and maintainable UI library

一日目 TrackA 13:30 〜 14:00 Kishikawa Katsumi (@k_katsumi)

優れたパフォーマンスと、可読性、テスト容易性を両立し、メンテナンス可能なソフトウェアを書くためのノウハウをお伝えします。私はたくさんのライブラリを公開しています。さまざまな状況で使われるライブラリでは通常のアプリよりも高いパフォーマンスと互換性の維持が求められます。 進化を止めず、互換性を維持することは簡単ではありません。またパフォーマンスの向上には多くの場合トレードオフがあります。そのことを理解し、ちょうど良いバランスの最適な選択をすることがエンジニアの腕の見せどころです。

セッション概要より引用

印象に残ったところ

• パフォーマンスチューニングをする上で大切なこと
  • 計測すること
  • トレードオフ
  • 多くの場合、速度を得る代わりに何かを失うことになる
    • 効果の小さいことに、高価なトレードオフをすることになってしまわないようにしよう
• トレードオフを知る
  • パフォーマンスチューニングには(ほとんどの場合)トレードオフが存在する
  • コードの読みやすさやテストのしやすさが犠牲になることが多い
  • 得るものと失うもののバランスの見極めがエンジニアの腕の見せどころ
• UIテストをしやすくするために
  • Viewの状態を表すモデルを用意して、Viewから分離してあげることで状態管理をしやすくする
  • 特定の条件(状態)というのを作ることができるようにしてしまえば、あとはいつもの値の検査と同じようにユニットテストすれば良いので、テストしやすくなる
  • テストしやすい構造にするためにはデータの流れを一方向にすることが大切

+α Q&Aしてきた

Q1:

DataSourceであったりConfigurationみたいなものをモデルとして分離することでUI要素の状態を切り出すことができて、それによってテストをしやすい状況を作ることができるとお話を読み取りました。 しかし最終的に行き着くところはUIViewになってしまうため、想定していなかった設定が行われてしまうことでバグが発生してしまうのかなと思いました。(これはUIViewControllerとかも同じで、UIKitフレームワークにまつわる呪いのようなものだと思っている) これを防ぐ方法としてなにか工夫していることはありますか？

A1:

どういうテストをしたいかという話になる。どうしても防ぎたい利用方法がある場合は特別にその利用シーンのテストを書いてしまうと良いと思う。

Q2:

Viewのもう一つ上の階層にManagerやFactoryみたいなものを用意して、ライブラリとしてはそれを使わせる、みたいなことをするべきでしょうか。

A2:

外部に対するアクセスコントロールとかAPIをどこまで公開するかという話ですね。この話も、最終的にはバランスの話になります。インターフェースを固定してしまえば、内部の変更をどう行うのも自由になる利点があります。SpreadsheetViewも「継承させて欲しい」という要望がきているが、今のところまだ許可していない。もうちょっとバージョンが進んで、インターフェースが固まってからそういう対応をしていこうと思っています。

感想

考えが整理される良いセッションでした。UIのテストをいかに行うかという話がとても参考になりました。

自分も簡単なUIライブラリを作った経験があり、Q&Aで聞いた内容が方針として正しいかという疑問を持っていました。設計に関する方針の認識が大きくそれていないことが確認できてよかったです。