ホットペッパービューティーアプリリプレイスとmvcp

ホットペッパービューティー

アプリリプレイスとMVCPCAMPFIRE iOS #1 2017/03/16 @nirazo

誰

• 韮澤賢三（にらさわけんぞう）

• （株）リクルートライフスタイル

ホットペッパービューティー iOSアプリ開発担当

• 日本グミ協会CTO (@gummi_life)

今日話すこと

• ホットペッパービューティーアプリリプレイスの背景と説明

• リプレイスで採用したMVCPの実装方法の説明

• MVCPを導入してみた結果（良さ）について

アプリリプレイス？

• Ver1.0リリースは2010年8月

• 6年半、秘伝のソースコードに継ぎ足し継ぎ足し…

• 仕様が詳細にまとまっていない部分も多々

• かつ複雑な仕様も多々…

2000行超え、1000行超えVC続出

LOCは20万行弱

明確な設計指針は無い

リプレイスして未来を照らそう

リプレイスで目指していること（要約）• 今後5年、10年と安全かつ素早くサービスのエンハンスが行えるようにする

• そのために明確な設計指針を設け、コード品質を安定化させる

• テスト対象が明確で、テストコードが書ける作りにする

本日の話の前提

• 本リプレイスは現在進行中（7~8割程度実装済み）であり、今回の話も未リリースのプロジェクトについての話です

• Obj-C -> Swiftの言語リプレイスも同時にやっています

今日話すこと




MVCP?

• iOS版MVP

• Model, ViewController, PresenterだからMVCPでは！？という議論（？）の末命名

MVCP?

MVP (Passive View)のiOSバージョン

ViewController

ViewControllerの特性• View, Presenterを所有、管理できる

• Presenterからはクロージャ、Notificationによってのみ通知を受け付ける

• ライフサイクル系やAutoLayoutの処理等、必要最低限に留める（ホットペッパービューティーではSnapKit使用）

• テストコードを書く対象になる処理は書かない

ViewControllerの役割

• ライフサイクル系

• Viewの更新

• UIパーツのアクション

• アニメーション

• 画面遷移

• ダイアログ／アクションシート

• Notificationの受け付け

Presenter

Presenterの特性

• 表示用データの取得、加工

• Viewと直接やりとりは行わない（VC経由）

• Modelを所有、管理できる

• ほぼ1VCに1Presenter

• テストコード記述対象

Presenterの役割

• UI入力のチェック

• Modelのデータの表示用の加工

• 表示用データの取得・保持

• （Closureをもらって）Viewの更新

• 画面に依存したロジック

• 効果計測用ログ送信処理

Modelの特性

• ビジネスロジックを実装するレイヤー

• テストコード記述対象

Modelの役割

• ビジネスロジック

• 我々のアプリだと、単純にAPIを叩いてcallback実行、というケースが多い

• API追加読み込み制御

• UserDefaults, DBへのアクセス

実装例

エリア選択画面

ViewController

Presenterを保持

メソッドはライフサイクル系に留め、それ以外のメソッドは極力VCには書かない

(UINavigation絡みはVCに書く)

計算等の処理自体はPresenterに任せる

Presenter

Modelを保持（複数APIを呼ぶ際は複数可）

ModelにAPI叩かせる

表示に関連するenumはPresenterで保持

row数やsection数など、表示に

関連するロジックはPresenter持ち

Model

API通信を行う

API側でビジネスロジックを持っていない部分については、Modelにビジネスロジックを記述

今日話すこと




何故MVCP？

• 設計自体の学習コストと得られるメリットのトレードオフ

• 検証用アプリを小さく作る中で、少ない学習コストで恩恵が受けられそうな見込みがあった

入れてみて

• 導入のハードルが低い！

• 新規参画者も理解しやすい

• ViewControllerの見通しが良くなる

• UnitTest可能範囲が明確

なところ

入れてみて

• 導入のハードルが低い！

• 新規参画者も理解しやすい

• ViewControllerの見通しが良くなる

• UnitTest可能範囲が明確

なところ

想定どおり！！

入れてみて

• MVCと比べると登場人物が増えてしまう…

• が、「書くのしんどい！」というレベルでは無い

• 我々のアプリだとModelの役割が少し軽すぎてただのパイプになっている感あり

なところ

入れてみて

• MVCと比べると登場人物が増えてしまう…

• が、「書くのしんどい！」というレベルでは無い

• 我々のアプリだとModelの役割が少し軽すぎて少しもったいない感あり

なところ

正直デメリットはそこまで感じなかった

入れてみての実績

Before (.mファイルのみ)

After （実装7割程度）

LOC 182612 70722

実装ファイル数 847 648

まだまだ課題はあるものの、見通しはかなり良くなってます

入れてみての実績

• テストコードは絶賛実装中！！

まとめ

MVCPはバランスが取れてて良い

• 1x万行レベルのアプリでも、恩恵は十分に得られる

• 疎にしてテスト範囲の明確化

• VCの見通しをクリアに

• 学習コストが低く、とりあえずで試しやすい

• Modelが複雑化してきたらClean ArchitectureやVIPERに比較的移行しやすい

iOSアプリの設計に悩んでいる皆さま

まずはライトに、MVCPから始めてみては？

~ fin ~

ホットペッパービューティーアプリリプレイスとmvcp

Engineering