heyに入社して3ヶ月になりました、iOSアプリエンジニア・ととです。 heyのモバイルエンジニアってどんなことをしているのか、というお話を前編・後編に分けて書いています。前編では、わたしが STORES モバイル本部決済グループで、エンジニアとして立ち上がるまでのお話を書きました。今回は、STORES 決済モバイルアプリの開発体制やiOS アプリ開発における採用技術についてご紹介します。

開発体制

f:id:totokit4:20211223150039j:plain

STORES 決済モバイルチームには、iOS3名、Android2名+インターン1名が在籍しています。ほぼフルリモートで開発をしており、なんとインターン生は大阪から参画しています。チームにはお子さんのいるパパが2名おり、子どもの事情で早めに仕事を始めたり上がったり柔軟に仕事をしています。（写真は STORES レジのエンジニアもいます）

iOSアプリの開発言語と主要フレームワーク

STORES 決済（当時はCoiney）は2013年から稼働している歴史が長いアプリでして、元々はObjective-Cで書かれたアプリでした。 2年前からフルスクラッチでのSwift化プロジェクトがスタートしていて、近々リリース予定です。新規開発はSwiftで実装しています。その際のリファクタリング手法はiOSDC Japan 2021に寄稿した記事をiOSアプリエンジニアが寄稿しておりますので、宜しければご参照ください。

iOSDC2021にて公開した｢約3年続くリファクタリングを引き継いで見えたテクニック｣のご紹介 - hey Product Blog

iOSアプリのアーキテクチャ

Clean Swiftを採用しています。元々はMVCを採用しており、コードが肥大化が課題となっていたので、Clean Swiftを導入して改善しました。

CI/CD

f:id:totokit4:20211223150122p:plain

Bitrise

毎日のビルド、テスト、デプロイに利用しています。

Fastlane

テストやDangerの実行、App Store Connectへのアップロードの自動化のために利用しています。

Danger

プルリクエストのレビュアーの負担削減のため、静的チェックを任せています。

TestFlight

QAチームへのテストの配布にTestFlightを利用しています。

開発フロー

要件検討

プロダクトマネージャー（PM）、デザイナー、バックエンドエンジニア、iOSアプリエンジニア、Androidアプリエンジニア、QAエンジニアで要件を決めていきます。

f:id:totokit4:20220107104641p:plain 会議は基本的にオンラインです。

前編で書いたように、改修内容に対してエンジニアも「実現可/不可」だけでなく「ユーザーにとってはこっちの方が良いのではないか」という提案することもあります。

設計実装

コード書いてる途中で方針や仕様に悩んだら、SlackやGitHubのコメント、Google Meetで気軽に相談できます。相談相手は、同じiOSエンジニアやAndroidエンジニアにとどまることもあれば、PMやデザイナー、QAエンジニアまで様々です。

コードレビュー

お馴染みGitHubでプルリクエストを出します。プルリクエストにはテンプレートで、Issueのリンク、対応内容、動作確認内容を書くように促しています。 f:id:totokit4:20220105172351p:plain レビュアーは、書かれた情報を元にレビューをします。マージの条件は、以下のようになっています。

1人以上のapproved
自動テストの成功
Lintのチェック

テスト

自動テスト

自動テストを積極的に書くようにしています。プルリクエストを出すと自動でBitriseのジョブが走り、自動テストが動くのですが、テストが成功しないとマージはできないようになっています。

QAエンジニアによるテスト

STORES 決済チームにはQAエンジニアがいます。先述の通り、テストの設計、スケジューリング、実施だけでなく、要件の検討から参加しています。エンジニアが見逃していた仕様の穴に気付いていただくこともあり、QAエンジニアの方には頭が上がりません。 QAエンジニアの取り組みについてはこちらの記事をどうぞ。

より良い品質を作り上げるためにQAチームが取り組んでいること ~QAチームのワークショップ事情~ - hey Product Blog

ブランドテスト

決済サービスならではですが、カードブランドから提示されているテストがあります。改修内容によっては、このテストをクリアする必要があります。サービス提供には、各種ブランドにで決められているレギュレーションに準拠していなければならないので、改修を検討する時点で様々な要件を考慮しています。

技術課題

アーキテクチャー

現在、STORES 決済 iOSアプリには、状態を持つレイヤーがありません。データの流れや責務はあるのですが、状態の不整合が起きやすい作りになっており、改善したいと考えています。また、採用しているClean SwiftはInteractorクラスが肥大化しがちです。こちらは今後、Workerクラスに処理を委譲していく予定です。

自動テスト

Unitテストは書かれているのですが、新機能追加したら必ず書く、みたいなルールは特に決まっていません。今後もっとテストコード周りは整備していきたいと考えているので、テストコードを増やしていく文化を作っていこうとしています。また、STORES 決済では、決済端末（カードリーダー）やプリンターと接続して実現できる機能があります。自動テストで、こういったハードウェアをモックして実機を使わなくてもテストができるようにして行きたいと考えています。