この記事は2017/03/16(木)にLODGEで開催されたCAMPFIRE iOS #1の絶対ブログ書く枠の記事です。遅くなったけど、ブログ書いたからね！
プロフィールはConnpassからの引用です。
最適な設計でアプリを作る
田中 達也 (@tattn) ◆ ヤフー株式会社 Yahoo!路線 エンジニア
2016年度新卒入社。Yahoo!乗換案内のiOSアプリを担当。
iOSやSwiftに熱中しており、良い実装の探求や開発環境改善に積極的に取り組んでいる。
途中から来たので、すべて聞けてはいないのですが、
アーキテクチャの選定はチームで相談しましょうというのが肝だった模様です。
詳細は、他の方がまとめていますね📦
参考：[イベントレポート] CAMPFIRE iOS #1 に参加して来ました！ #yjcamp
Wantedly Peopleがたどり着いたアーキテクチャ
多和田 侑 (@yuta24) ◆ Wantedly, Inc. エンジニア
Wantedlyのエンジニア。新卒で組込み系ソフトウェア開発会社に入社し、カーナビのソフトウェア開発に従事。だが、スマホの勢いを感じてソーシャルゲームを開発している会社に転職。そこから、いくつかの会社を経て、2016年9月にWantedlyに入社。現在はWantedly PeopleのiOSアプリの開発を担当。
リリース初期はMVVM × RxSwift + Realmにしていたとのことです。
RxSwiftはAPIの直列、並列化が行え、Realmはオフライン時のデータ参照に利用しています。
この構成のお話は杉上さん(@susiyy)が昨年Realm meetup #19で発表されていましたね。
リリース後はMVVM + Interactor + Routerを加えた構成に。
ディープリンクが入ってきた関係で、画面遷移をRouterに任せ、
画像のアップロードなど、各ViewModelが使う共通の処理をInteractorにまとめることで、ViewModelの役割を小さくしています。
ホットペッパービューティーリプレイスとMVCP
韮澤 賢三 (@nirazo) ◆ 株式会社リクルートライフスタイル ホットペッパービューティーアプリエンジニア
2012年に大手Webサービス企業に新卒入社し、新規アプリ立ち上げの開発に従事。その後iOSアプリやサーバサイドJava等の開発を経験し、2015年秋にリクルートライフスタイル入社。新規アプリ開発に携わった後、現在はホットペッパービューティーアプリの開発チームリーダー、アプリリプレイスプロジェクトリーダーを担当。 グミが好きすぎて毎日食べている。推しグミはピュアラルグミ。
アプリをリプレイスするにあたって、採用したMVCP(≒MVP)のお話です。
同時にObjective-CからSwiftへのリプレイスも行ったようですね。つらいですね😇
基本構成はこんな感じ
ViewController
Presenter
Model
- ビジネスロジック(APIを叩いたり)
- UserDefaults, DBへのアクセス
良いところ：ViewControllerの見通しがよくなったり、テストしやすくなった。学習コストが低い
🤔なところ：登場人物が増えたが、そんなに書きにくいわけではない。
どのアーキテクチャを採用しても、チームでの認識合わせは必要ですが、
MVCにPresenterを導入することで、ViewControllerの役割を軽くしているだけなので、確かに導入コストは低そうな感じもしました。
独自のアーキテクチャではあるので、新しいメンバーが入る度に認識合わせは必要になるかと思いますが、どのアーキテクチャでも同じ問題は発生するので、ここがアーキテクチャ選定のネックになるということはないのかなぁという印象です。
10分で振り返る、ソフトウェアアーキテクチャの歴史2017
関 義隆 (@takasek) ◆ フリーランス(ほぼ株式会社FiNC)
かつてExcel方眼紙を操るCOBOL育ちの深海魚だったが、Excelマクロへの興味をきっかけに進化、PHP、JavaScript、ガラケーFlashなどを経て7年前iOSに上陸し、ついにSwiftという翼を手に入れた。最近は主に株式会社FiNCさんで大規模チーム開発に刺激を受けている。型と設計が好き。
MVCからはじまり、DCI, MVP, MVVM, Flux。また、Layered Architecture、Hexagonal Architecture、Onion Architecture、Clean Architecture、VIPER、Minimum Viable Archtitectureまで歴史を振り返ってくださいました。10分で振り返るにはだいぶ無理があったようなので、ぜひ30分ぐらいお聞かせいただきたいなと思いました。2017年はきっと関さんがこれまでの歴史を反省して、新しいアーキテクチャを提案してくれることでしょうね！
マネーフォワードの設計へのアプローチ
児玉 孝太郎 (@koutalou) ◆ 株式会社マネーフォワード
2010年に広島市立大学大学院修了後、株式会社ACCESSに約5年間勤務。IoTソリューションやHEMSの企画・開発を担当する。2015年に株式会社マネーフォワードにジョイン。主にPFMサービスのiOS,Androidアプリケーション開発に従事している。
Architectureについて
児玉さんと言えば説明不要でこの記事ですね。
まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて
Architectureの選定
Architectureやその選定方法についてお話されていました。
特定のレイヤが複数の責務を持ち依存度の高い複雑なコードが生まれるような状態なら、
VIPERやClean Architectureの採用を検討してもいいけど、
一人で開発したり、スモールスタートでやりたいような場合は、向いてないとのこと。
プロジェクトの状況やメンバー、サーバー側も含めた全体のシステムを考慮して、Architectureを選定すべき
Clean Architectureへの取り組み
- チームで言語化された定義があることが大事で、さらに暗黙知になるぐらいに熟知していること
- Presentation, Domain, Data Layerは全てProtocolを定義 Application LayerでImplementationをDIする
UI Componentの共通化をFrameworkで行っていると。
ここは浅井さんの作ったNoriに近いものを使っていると。
あーでもこれ作るのめんどくさいですよねーという方には、同社の廣瀬さんが作ったKuriというクリーンアーキテクチャーのコードジェネレーターがありますね。
参考：bannzai/Kuri
Delegateパターンがつらすぎるので、RxSwiftもつかっていて、Promise処理を容易にしていたり、Protocol Oriented Programmingも意識していて、
PresenterとView以外はStructで定義してるとのことです。
一部のレイヤーをMockで差し替えることで、テストも容易になりますね。
Architectureに銀の弾丸はないので、何が最適か考え続けることが大事ということでした。
また、良い質問が飛んでました。
Yahoo! JAPAN アプリという大規模アプリの設計と開発
作井 吉満 (@ysakui) ◆ ヤフー株式会社 Yahoo! JAPANアプリ エンジニア
某居酒屋チェーンにて、店舗責任者として勤務。
大阪から富山まで、多くの新規出店を成し遂げたのち、IT業界に興味を持ち新卒でYahoo! JAPANへ入社。
様々なWebサービスのフロントエンド開発を担当後、2012年からアプリ開発へシフト。
Yahoo! Sonomyなどいくつかの新規サービスの立ち上げを経験したのち、現在はYahoo! JAPANアプリ iOS版のリードエンジニアとして全体設計と開発を担当。
Swiftに移行するために、1年半かけて移行を行ったとのことです。つらいです。
10人以上で開発すると、全員で集まるのも難しく、仕様のすれ違いも起こるということで、MVCのようなアーキテクチャで進めるのは難しいとのことでした。
懇親会
ヤフーさんは🍣をよく出してくださる会社です。個人的に🍣を出してくださる会社は好感度高めです。
まとめ
アーキテクチャのことを考える必要のある大きな会社におられるiOSエンジニアが、日々どのようなことを考えてアーキテクチャを導入・運用しているかを垣間見れた会でした。昨年は、RxSwiftの普及でMVVMの普及が一気に広まった年だったように思いますが、アーキテクチャの悩みは2017年になってもつきない感じがします。どの方もアーキテクチャには銀の弾丸はなく、チームの規模や、アプリの状態に応じて選定する必要があり、チーム内での共通認識を言語化できるレベルまで落とし込む必要があるということをお話されていました。個人的にはMVVM程度のアーキテクチャで十分機能しているので、アーキテクチャのこと考えなきゃいけないほど巨大なアプリを作られている方は大変だなぁという気持ちになりました。