おばんです、最近買ったボイスチェンジャーの力によって可愛い女の子（の声）になりつつある田中です。
先日1月15日に書籍『iOSアプリ設計パターン入門』の発刊を記念して、弊社主催で「iOSアプリ設計ナイト」という勉強会を開催しました。今回はそのレポートをお送りします。
ビールでカンパイ
イベントは乾杯からスタート。iOSDCでビール舌の肥えたiOSエンジニアの方でも満足いただけるように、美味しいビールをご用意いたしました( ˘ω˘ )
設営完了しました！お待ちしております！ #pixiv_ios_arch pic.twitter.com/bfgqremRja
— Atom（アトム） (@FromAtom) 2019年1月15日
ここから先は今回行われた5つの発表の内容と感想をお送りします。
「2つの同期 4つの状態」 @ktanaka117
発表の内容
- マーティン・ファウラー氏のサイトを参考に、2つの同期方法と4つの状態(データのコピー)を紹介し、そこからアーキテクチャパターンの違いについて迫る内容でした
- アーキテクチャはパターンが先にあるのではなく、要件を元に同期方法と状態の持ち方を検討してできあがり、それが頻出なものがパターンとして名前付けされているという解説でした
- 同期方法と状態の持ち方の違いを把握することで、各パターンの違いについても理解しやすくなるはず
筆者の感想
この発表は筆者が登壇者だったので、登壇者としての感想です。
2つのデータの同期方法（フロー同期とオブザーバー同期）について解説しましたが「普段使っていたけど、名前を知らなかった/体系だったことは知らなかった」という声をいただけて、発表した甲斐があったなと思いました。
アーキテクチャパターンが先に立って形から知ることも多いと思いますが、それぞれのパターンの差分を知るには同期方法と状態の持ち方の違いについて知る必要があります。パターンについて考える機会があれば、ぜひ同期方法とデータの持ち方に着目してみてください。
「橋の下で安心して寝るための『iOSアプリ設計パターン入門』」 @kameike
発表の内容
「ローマ時代のエンジニアは、自分の建てた橋の下でしばらく過ごさなければならなかった。」（『反性脆弱［下］――不確実な世界を生き延びる唯一の考え方』）という言葉に感銘を受けたとのこと
- これは自分が作った橋の下に寝ることで、安全性を担保して誇れる建築の仕方をしたことの証明になる
- ソフトウェアの設計も同じで、自分が取り入れた設計には責任を負いましょうということであり、自分が行なった判断に誇りを持ちましょうということ
また、マンガアプリのPalcyで実際に行われている試行錯誤を紹介いただきました
- Palcyでは「漸進的成長」を念頭に置いて、「縦割りのグループ構造」（機能単位でグループを割り振る構造。対は役割単位でグループを割り切る横割りのグループ構造がある。）を採用している
- 縦割りにした上で、そのグループのルートにREADME.mdを置いて、「この機能の設計はxxxを採用しています。経緯はyyyです。etc...。」と補助的な情報を記載して運用している
- 最近はBLoCパターンを採用している
筆者の感想
GoFのデザインパターン本を読んでソフトウェア業界に入ったとのことなんですが、すごい稀有ですよね...！
私もグループの分け方はしばらく悩んでいますが、最近は縦割りのグループ構造に軍配があがっています。発表の中であった「漸進的設計改善」に適しているからです。
アプリの生存期間が長く複雑になっていく中で、設計改善は必須になってきています。 その改善を機能単位で切り分けていけることに魅力を感じています。単にアプリ全体の方針のみでなく、「この機能はこの設計の方が良さそうだ」ということにも対応できる点も良いです。
あとREADMEを置くのはドキュメントメンテ問題もありますが、経緯を記載しておけて最高そうだなと思いました！
「iOSアプリ設計パターン選定」 @d_date
[のちほど公開され次第スライドを挿入します]
発表の内容
- アーキテクチャパターンを選定するための要素は機能要件以外にも色々あります。そのいくつかをピックアップして投げかけるような発表でした
- 「このあたりのことは13章に書いてあります。『iOSアプリ設計パターン入門』の13章を読んでください」
- 「設計パターンに正解はない」 by 色んな人
- 正解はないがパターンはあるので、適切なものを使い分けていきましょう
筆者の感想
終始同意の嵐です。『iOSアプリ設計パターン入門』の13章を読んでほしい...！
13章はアーキテクチャ選定はどうしたらいいか、そしてよくある誤解についてまとめられています。筆者一同「これが言いたかった！」を詰め込んだ本当に良い章です。
と、感想が本の宣伝になってしまいましたが、ぜひ！
「表示ロジックにおけるテスタビリティの獲得例」 @_ishkawa
発表の内容
- 表示ロジックをいかにテスト可能な形に持っていくか、現実的な解決案を紹介いただきました
- 画面に利用する状態の変化をテストするのが話の中心でしたが、保持する状態のテストのみでなく、場合によってはUIテストと使い分ける必要ももちろんあるとのこと
- ボタンタップなどの連続したUIイベントのテストも、RxSwiftの仮装時間を用いることでテストが容易になるというデモがありました
筆者の感想
UIテストはコストが非常に高いので、Presenter/ViewModelが保持する状態変化を見て表示ロジックのテストを行うことを、私もよく行います。
仮装時間は非常にテストと相性が良いのですが、多くの場合Rxを利用した方法になってしまうので、Rxに依存しない形だとどうやって実現できるか考えてみるのも面白そうだと思いました。
あと、自分が発表した内容のScreen/Presentation Stateの話がうまくつながってよかったです...！
「アプリ設計は何がつらいのか」 @takasek
[のちほど公開され次第スライドを挿入します]
発表の内容
- オブジェクトの生存期間が長くてつらい...、状態がミュータブルだからつらい...、要求変化がつらい...、様々な現実的なつらみを例示しながら、その解決策を一つずつ紹介いただきました。
- その話の一方でつらみとの使いには「たたかう」だけでなく「にげる」選択肢もあるんだよ、というカウンターパートも説明されました。
筆者の感想
つらみから「にげる」選択肢は良いなと思いました。自分は問題があるとあの手この手で「解決する」（＝たたかう）選択肢を取りがちなのですが、一歩俯瞰して、迂回することも戦略だなと。
状態を減らしてもいいんじゃないか、ごちゃごちゃした画面じゃなくてもいいんじゃないか、永続化しなくてもいいんじゃないか。そういった方向の豊かさもたくわえていきたいと思いました。
懇親会
- サブウェイ×ピザ×美味しいビール=最高
- 勉強会でサブウェイが出てくるのは見たことがなかったのでよかったです！美味しいし！
- 各々で設計に対する考えをすり合わせる良い回になっていたようでした
- （私は設計の話もする一方で、バ美肉とボイスチェンジャーの話ばかりしていました）
まとめ
示し合せるでもなくそれぞれの発表が関連しあっていて「さっきxxxさんが話していたこととつながるんですがー」みたいな相互リンクがされていて、相乗効果がある会になって素晴らしかったです！ 設計に慣れた人々の関心事や共通解が凝縮した良い会になりました。
また、70人の定員に対してピーク時は3倍を超える応募率をいただきありがとうございました！ 残念ながら全員にご参加いただくことはできませんでしたが、YoutubeのLIVE配信にも人がいっぱい来てくれて嬉しかったです。遠隔から参加してくれた人もありがとうございました！
さらにさらにありがたいことに、参加者の方がブログをまとめてくれました🎉
今後もこのようなイベントはまた開催していこうと考えているので、そのときはまた来てくださいねー！＾＾）ノシ
