LINE Developer Meetup(京都)#53 に行ってきました

お久しぶりです。転職ではないが東京に飽きて特に渋滞にうんざりしてしまって会社に「福岡行きたいです」って言ったら一人で福岡オフィス作った(と言う名のWeWork借りた)星野です。ちなみに福岡に移住したとは言え、iOS 系の勉強会がやはり少ないから、月一くらい東京の勉強会行くから旅費くださいって言えば出してくれる会社ですのでとても助かります。と言うわけで今回は東京ではなく京都に行ってくました:

line.connpass.com

LINE さん主催の勉強会で、一般公募登壇枠がなく全て LINE の社員による発表(しかも 3 枠のうち 2 枠は外国人社員による英語の発表)ですが、どれも内容がとても濃くて完全に吸収するのにはまだ少し時間がかかりそうです。と言うわけで復習も兼ねてこの記事で簡単にこれらの発表を振り返ってみます。

MVC @ IOS

speakerdeck.com

これは MVC パターンを綺麗にするための発表です

概要

  • 従来の (CocoaMVC パターンは VC(ViewController)が Fat になりがち
    • そのため MVP や MVVM などの設計が考案され、MVC はもう時代遅れと言う風潮になった雰囲気がある
    • しかし本当に MVC はそれほどダメなのか
  • iOS の VC と View は本来それぞれちゃんとした役割がある
    • VC は画面遷移、View のライフサイクルやイベントなどの管理を行う
    • 対して View は子ビューの階層構造、レイアウト、レンダリングやアニメーション等を行う
  • View を自作してみよう
    • 画面系のセットアップを VC から View に移行しよう、これで View のテストも作りやすくなる
  • VC から Model や Network などの要件もちゃんと分離しよう
    • これで Unit Test もやりやすくなる
  • 画面が複雑になってきたら子 VC の利用も検討しよう
    • 要件が単純化され、作りやすくなる
  • まとめ
    • MVC でも綺麗で読みやすい作りにできる
    • 汎用的で再利用しやすい UI を作ろう
    • 設計に銀の弾丸はない、ちゃんと自分たちで設計要件を検討しよう
    • もちろもちろん MVVM や Redux なども魅力的だよ!

感想

実は設計について、自分も去年こちらの本の執筆に参加しており、中でまさに MVC の章の執筆を担当しました:

peaks.cc

この章の執筆によって MVC の資料をたくさん漁って、実は今まで MVC に関する知識は間違っていた!?と言う反省を抱きながら、執筆に臨みました。そしてその感想として、やはり MVC でもきちんと設計を行っていれば綺麗なコードにはなるし、逆に何も考えずに Fat な VC を作っちゃうような人たちは、仮に MVVM や MVP とかの設計に転向したところで、Fat な ViewModel や Fat な Presenter を作ってしまうだけで終わりますので、やはりどの設計を選ぶか以上に、どの部品がどこまでの責務を持つかをきちんと考え抜いたほうが大事ですね!Fat VC を理由に MVC を拒まないようにしましょう、MVC も立派で偉大な設計パターンです。

Swift コードのための Swift プログラミング

speakerdeck.com

ちょっとわかりにくいようなタイトルですが、Swift プログラムで、Swift のソースコード(フォーマット)を綺麗にするための発表です

概要

  • SwiftSyntax と言うツールがある
    • これを使うと、特定なキーワードでワーニングを出したり、ソースコードを機械で生成/編集したりできる
  • SwiftSyntax はコンパイラ内部で使う libSyntax を利用し、構文を抽象化して解析したり作成したりできる
    • 具体的にはどんな型があって、中にどんなプロパティーがあって、どの protocol に準拠してるかだとか、様々な構文情報がわかる
    • それによってプロパティーの書き換えや場所の移動、private などの attributes の追加なども簡単に実現できる
    • 構文の解析には SyntaxVisitor を利用する
    • 構文の編集は SyntaxRewriter を利用する
    • 構文の生成は SyntaxFactory を利用する
  • 具体的な操作は上記のスライドを参考に

感想

実は今年の try! Swift Tokyo にもありました SwiftSyntax のネタですが、try! Swift の時は 5 分しかない LT だったので最低限のイメージの紹介しかできなかったが、この発表では時間がたっぷりありますので、具体的にどう言う風に使えばいいかだけでなく、実際にそのツールをすでに作って& OSS 化したので、より使いやすくなったと思います。特にチームで開発する際に、フォーマットの平準化にも役に立ちそうですので、いつか導入したいですね。今のところ唯一の懸念点は、どうやってコミットを実行済みの結果に保証するかの仕組みを考えないとですね…

Networking shouldn't be so hard

speakerdeck.com

これはネットワーク処理(リクエストやレスポンス)についての、非常に詳しい発表です

概要

  • ネットワーク処理は簡単か?
    • 理想論ならとても簡単
    • でも現実世界ではなかなかそうシンプルにはいかない
    • しかし本来ならばそう難しくなるべきでもない
  • 大昔のネットワーク処理は今と比べるとちょっと煩雑だった
    • NSURLConnection とかを使っていた
    • セッション管理とかキャッシュとか自力でやる必要があった
    • ただ別にそれでも特に難しくはなかった
  • 今はさらにいろんなラッパーライブラリーがある
    • URLSession とか Alamofire 使えばもっとやりやすくなっている
    • Client を作ってリクエストとレスポンスをセッション通じてさらに管理しやすくできる
    • レスポンスの面倒な (data: T?, response: URLResponse?, error: Error?) はさらに Swift 5 の Result<T, Error> でまとめられる
    • よってネットワーク処理は本当に(理屈上は)簡単
  • しかし現実世界はそう単純にいかない
    • リクエストのコンテンツは JSON Body なのか URL Query なのかだとか
    • 正常でないレスポンスが返ってきたときのハンドリングとか
    • ネットワークがつながりにくい時のリトライや Token が古くなった時の更新だとか
    • 現実世界で起こりうるシナリオの多さは問題を難しくしている
  • でも問題を単純化することは可能だしそうすべき
    • 各々の責務を細かく抽象化して分けよう
      • リクエストならリクエストを作る責務を抽象化して、内容に応じた具体的なリクエストの作りをその部品に任せよう
      • レスポンスなら意思決定ベースで continue restart errored done に抽象化してそれぞれの動作を実装しよう
    • リクエスト駆動でやることをリスト化する
  • 問題を細かく抽象化して対処すれば難しくない
    • 部品が小さくなるので見通しが良くなる
    • 副作用を排除したのでテストがしやすくなる
    • protocol の活用で実際のケースに応じた柔軟な対応がしやすい
    • 意思決定を基にした拡張性の確保
    • リクエスト駆動による操作性の向上
  • 結論:現実世界でもネットワーク処理は難しくないはず

感想

なかなか濃い内容で、これだけでも京都に来た甲斐はあったと思えるくらいのボリュームです。ネットワーク処理をどう単純化すればいいかなど、細かいところまでカバーしてたので今後の開発に参考にできるものも非常に多いです。ちなみに Speakerdeck に上がっている資料は 133 ページもあるのですが、発表者の @onevcat 氏によるとこれでもすでに初稿から 20 ページも削除したそうです…

あとがき

どうしても日帰りで福岡に帰りたかったので残念ながら懇親会はほんの少しだけしかいられなかったけど、久しぶりに京都勢に会えたので今度はぜひみんな福岡に来て欲しいw