「メルカリ・メルペイ・ヤフートップ・PayPayフリマのiOSエンジニア対談」参加メモ #merpay_techtalk
iOSエンジニア対談のオンライン勉強会に参加したのでメモ書きを投稿。
この記事では私が個人的に特に気になったところをまとめて抜粋。Togetterを見る方がより細かくわかるはず。
以下、メモ書き。
テスト
- メルカリではオブジェクトが解放されているかどうかのユニットテストが存在する
- 動作確認にはリモートツールも使っている
- メルカリではRemote TestKitを使い始めている
- YahooではAppliCatを使っていて、WebUIでテストができる。が、重いので実機確認の方が多い。
- アプリが大きくなってもテスト実行速度が落ちないように工夫してる
- できるだけ単体で実行できるようにしたり、変更が入ったモジュールだけ動かすようにしてる
- UIテストで使っているツールはプロジェクトによって異なる
- メルカリ：Appium
- メルペイ：XCUITest。ログインなどクリティカルなところをメインにカバー。
- PayPayフリマ：費用対効果を考慮してやめた。代わりにユニットテストを増やしている
- テストカバレッジ
- Yahoo：75%
- PayPayフリマ：64%
- 非同期周りのテストはMockoloを使おうとしている
アーキテクチャ
- PayPayフリマでは、クリーンアーキテクチャをテスト的に導入
- 週1で勉強したり、副業など外から得た知識をペアプロで共有したりした
- 画面遷移はCoordinatorパターン
- VC/View以外はFrameworkに切り出している
- テンプレートを選ぶとボイラーテンプレートが自動生成されるようにしている
- メルペイは基本MVVMで、アーキテクチャオンボーディングはほぼなし
- 極力OSSを使わないようにしてる
- ReactiveSwiftも使わず、プレーンなObservableを使っている
- おかげでオンボーディングコストもあまりない
- メルカリはMVVM、Flux＋MicroViewController
- 1つのVCに複数の開発が走ることがあるが、このアーキテクチャによって並行開発がしやすい
開発プロセス
ブランチ運用
- メルカリではブランチをマージする前にQAを実施
- 最後サブミット前に再度テストを実施
- Yahoo!Japanアプリではマージした上でQAを実施
- テストが完了したらフィーチャーフラグを変える
- メルカリではブランチのオートマージをやっている
- 毎晩botが自動でdevelop -> 各ブランチをやってくれる
- コンフリクトがなければ即マージ、コンフリクトしてたら手動マージ
技術負債の返済
- メルペイでは負債を返済するためのチーム、プロジェクトをEMが用意する
ビルド速度
- メルカリではモジュールごとにサンドボックスアプリがある
- メルカリではEmbedded Frameworkは導入しているが、それによってビルド時間が削減されたかんじはしない
- Static Framework化して起動時間を短くするようにするなどもやっている
ローカライズ
- ローカライズメッセージの管理、運用はあまりやっていない
- メルカリは公式サポートしているのは日本語だけ。ただ開発メンバーには非日本語ネイティブがいて何が書いてあるかわからないこともあるので、dev環境だけ英語への自動翻訳がされるようにしている
- メルカリではデザインシステムやローカライゼーションは外部モジュールにして、必要なときにimportしている
対応OSバージョン
- 対応OSバージョンの下限は、理想は直近2バージョンだが、実際には3バージョンくらい
- ユーザ数、GVMの影響を加味する
- 今度から、WWDCで新しいバージョンが発表されたらディスカッションすることに決めた
API通信
- メルカリ、メルペイではProtocol Buffersを採用
- 型周りの心配がなくなる
- PayPayフリマではBFFを使用
- iOSエンジニアがBFFを開発することもあり、型の認識がずれることはそこまでない
