ここ最近、フルスクラッチのiOSアプリ開発でVIPERアーキテクチャを使用して、開発したので、感想を書いてみます。
はじめに
開発期間が３ヶ月ほどのiOS新規開発アプリで、Swift VIPERアーキテクチャを使用したアプリを開発しました。
途中まで、シンプルなMVCで作成していましたが、いまいちだったのでVIPERを気まぐれで採用した感じです。
いきなり結果ですが、見通しがよく、改修しやすい、品質の高いアプリを実装出来たので、今後も新規開発で採用していこうと思ってます！
あとは、そろそろ誰がガチガチのiOSのフレームワークを作ってくれないかなーと
参考にした資料
- iOS Project Architecture: Using VIPER
- iOS Project Architecture : Using VIPER [和訳]
- VIPERアーキテクチャ まとめ
- MindorksOpenSource/iOS-Viper-Architecture
VIPERを使って特によかったところ
- 理解と導入が楽(Clean Architecture / MVVMと比べて）
- 他のアーキテクチャと比べて、良い意味で奥が深くないと思うので、気楽に導入できる
（MVC、MVVMは毎回色々悩むので） - 慣れると、流れ作業で画面を量産できる
- 適当に作っても、ルールにしたがっていればそれなりに綺麗にできる
(ロジックをInteractorにぶち込む） - 他の案件に使いまわせる実装がかなり多いイメージ
- ViewController内に、画面遷移のコードを書かなくて良いのがすごくかっこいい
- ロジック、WebAPIの仕様変更があっても、ViewControllerまで変更が入ることが少なかった
メリット詳細
- プロジェクト構成を悩まなくて良い
- MVCで開発する速度と、慣れさえすれば変わらないと思う
- ViewControllerを徹底的に軽くできる
- APIの仕様変更時に、ViewControllerを変更しなくて良い確率が上がる
- 途中まで、MVCで作っていた物を、さほど苦戦せずにVIPERに変更できた
- MVVMとは違い、ロジックの処理をまとめやすい
- 開発が進むにつれて、開発速度をどんどん上げることが出来た
- 開発が進んでも一定の品質を簡単に保てた
- 複数人開発の時に、基準ができるので無駄な争いが起きなそう
- 各階層ごとの役割が明快なので、コードレビューもしやすいはず
- エラー表示処理や、インジゲータ表示処理などをViewControllerのExtensionにまとめると、使いまわしがすごくしやすい
- 無駄な条件分岐の実装が極端に減った
- プログラム内のネストが極端に減った
- 多分、UTもしやすいはず（そんな工数はもらってないので、やってない）
デメリット詳細
MVCと比べて、開発速度が下がると行ったこともほとんどないので、デメリットはほとんど無しです。
- 開発の初期は、プロジェクトの構成作りに悩んでしまったので、時間を浪費した
- 当たり前だが、引き継ぎ時にアーキテクチャを相手に理解してもらう必要が出てきた
- 日本では、RxSwiftを使ったMVVMの方が流行ってるイメージ
悩んだところ
- 色々なサンプルをみたが、割とみんなバラバラなプロジェクト構成、作りになっている
-> PHPのフレームワークのようにガチガチな規約があると考えなくて助かるのになぁと - Interactorを使い回す時の取り回し
-> DIする時にまとめて渡す方式にした - Protocolの置き場所
-> モジュールごとに1ファイルにまとめた - View -> Presenter部分のメソッド名の付け方
-> 結局アクション名でつけた 例)didPushHoge, didSelectHoge
失敗したところ
- ViewControllerに少しロジックが乗ってしまった
- 前の画面に戻る遷移は、全RouterにInterfaceでつければよかった
- モジュールの自動作成をできるようにすれば、もっと工数を下げれた
次回以降、気をつけたいところ、やりたいこと
- 公開できるレベルの実際に動作するサンプルPJを作りたい
- VIPER + Rxでいい感じになるかも
- View -> Presenter部分のメソッド名の付け方を再考する
- モジュールのテンプレをコマンドで作成できるようにする
- RouterのViewController生成部分でNavigationControllerを渡したのはよくない