LINE Developer Meetup(京都)#53 に行ってきました
お久しぶりです。転職ではないが東京に飽きて特に渋滞にうんざりしてしまって会社に「福岡行きたいです」って言ったら一人で福岡オフィス作った(と言う名のWeWork借りた)星野です。ちなみに福岡に移住したとは言え、iOS 系の勉強会がやはり少ないから、月一くらい東京の勉強会行くから旅費くださいって言えば出してくれる会社ですのでとても助かります。と言うわけで今回は東京ではなく京都に行ってくました:
LINE さん主催の勉強会で、一般公募登壇枠がなく全て LINE の社員による発表(しかも 3 枠のうち 2 枠は外国人社員による英語の発表)ですが、どれも内容がとても濃くて完全に吸収するのにはまだ少し時間がかかりそうです。と言うわけで復習も兼ねてこの記事で簡単にこれらの発表を振り返ってみます。
MVC @ IOS
これは MVC パターンを綺麗にするための発表です
概要
- 従来の (Cocoa)MVC パターンは VC(ViewController)が Fat になりがち
- iOS の VC と View は本来それぞれちゃんとした役割がある
- VC は画面遷移、View のライフサイクルやイベントなどの管理を行う
- 対して View は子ビューの階層構造、レイアウト、レンダリングやアニメーション等を行う
- View を自作してみよう
- 画面系のセットアップを VC から View に移行しよう、これで View のテストも作りやすくなる
- VC から Model や Network などの要件もちゃんと分離しよう
- これで Unit Test もやりやすくなる
- 画面が複雑になってきたら子 VC の利用も検討しよう
- 要件が単純化され、作りやすくなる
- まとめ
感想
実は設計について、自分も去年こちらの本の執筆に参加しており、中でまさに MVC の章の執筆を担当しました:
この章の執筆によって MVC の資料をたくさん漁って、実は今まで MVC に関する知識は間違っていた!?と言う反省を抱きながら、執筆に臨みました。そしてその感想として、やはり MVC でもきちんと設計を行っていれば綺麗なコードにはなるし、逆に何も考えずに Fat な VC を作っちゃうような人たちは、仮に MVVM や MVP とかの設計に転向したところで、Fat な ViewModel や Fat な Presenter を作ってしまうだけで終わりますので、やはりどの設計を選ぶか以上に、どの部品がどこまでの責務を持つかをきちんと考え抜いたほうが大事ですね!Fat VC を理由に MVC を拒まないようにしましょう、MVC も立派で偉大な設計パターンです。
Swift コードのための Swift プログラミング
ちょっとわかりにくいようなタイトルですが、Swift プログラムで、Swift のソースコード(フォーマット)を綺麗にするための発表です
概要
- SwiftSyntax と言うツールがある
- これを使うと、特定なキーワードでワーニングを出したり、ソースコードを機械で生成/編集したりできる
- SwiftSyntax はコンパイラ内部で使う libSyntax を利用し、構文を抽象化して解析したり作成したりできる
- 具体的な操作は上記のスライドを参考に
感想
実は今年の try! Swift Tokyo にもありました SwiftSyntax のネタですが、try! Swift の時は 5 分しかない LT だったので最低限のイメージの紹介しかできなかったが、この発表では時間がたっぷりありますので、具体的にどう言う風に使えばいいかだけでなく、実際にそのツールをすでに作って& OSS 化したので、より使いやすくなったと思います。特にチームで開発する際に、フォーマットの平準化にも役に立ちそうですので、いつか導入したいですね。今のところ唯一の懸念点は、どうやってコミットを実行済みの結果に保証するかの仕組みを考えないとですね…
Networking shouldn't be so hard
これはネットワーク処理(リクエストやレスポンス)についての、非常に詳しい発表です
概要
- ネットワーク処理は簡単か?
- 理想論ならとても簡単
- でも現実世界ではなかなかそうシンプルにはいかない
- しかし本来ならばそう難しくなるべきでもない
- 大昔のネットワーク処理は今と比べるとちょっと煩雑だった
NSURLConnection
とかを使っていた- セッション管理とかキャッシュとか自力でやる必要があった
- ただ別にそれでも特に難しくはなかった
- 今はさらにいろんなラッパーライブラリーがある
URLSession
とかAlamofire
使えばもっとやりやすくなっている- Client を作ってリクエストとレスポンスをセッション通じてさらに管理しやすくできる
- レスポンスの面倒な
(data: T?, response: URLResponse?, error: Error?)
はさらに Swift 5 のResult<T, Error>
でまとめられる - よってネットワーク処理は本当に(理屈上は)簡単
- しかし現実世界はそう単純にいかない
- でも問題を単純化することは可能だしそうすべき
- 問題を細かく抽象化して対処すれば難しくない
- 部品が小さくなるので見通しが良くなる
- 副作用を排除したのでテストがしやすくなる
protocol
の活用で実際のケースに応じた柔軟な対応がしやすい- 意思決定を基にした拡張性の確保
- リクエスト駆動による操作性の向上
- 結論:現実世界でもネットワーク処理は難しくないはず
感想
なかなか濃い内容で、これだけでも京都に来た甲斐はあったと思えるくらいのボリュームです。ネットワーク処理をどう単純化すればいいかなど、細かいところまでカバーしてたので今後の開発に参考にできるものも非常に多いです。ちなみに Speakerdeck に上がっている資料は 133 ページもあるのですが、発表者の @onevcat 氏によるとこれでもすでに初稿から 20 ページも削除したそうです…
あとがき
どうしても日帰りで福岡に帰りたかったので残念ながら懇親会はほんの少しだけしかいられなかったけど、久しぶりに京都勢に会えたので今度はぜひみんな福岡に来て欲しいw