ID:20420さん

## 背景 アプリの内製化に伴い、運用保守や品質の向上、ECアプリ開発経験のUI/UXを生かすためプロジェクトにJoin。 ## やったこと #### 実装面 　テスタブルな開発を可能にするためDI（Dependency Injection）やRepositoryパターンの導入。 　それにより、ViewModel等のテストが書きづらかった要素のUnitTestを可能にした。 　カバレッジがほぼ0%だったものを高いもので70%まで引き上げ。 　ライブラリ等に切り出せるものはEmbedded Frameworkとして切り出し。 　MVCに近い形で実装されていたものをRxSwiftを用いたMVVMに変更。 #### 生産面 　①開発に集中する環境を作るため、fastlaneを用いて以下の点を自動化しました。 　　・UnitTest 　　・Beta配布 　　・iTunes Connectアップロード 　②テストの習慣や実装のコンパイル時間を意識させるために、dangerやfastlaneを用いて、以下の点の見える化。 　 　・カバレッジ 　・ビルド時間 　見える化については、週に1度上記項目の数値をSlackに通知するようにしました。 　数値の見える化によって、ビルド時間がかかっている箇所についてリファクタリングしようとする動きが 　活発になりました。 　また、ユニットテストについてもかなり習慣化され、 　レビューの時点でテストについての指摘もされるようになりました。 　③実装にばらつきが出ないように実装の規約的なものを作成しました。 　　個人間で実装のばらつきが出てしまい、どう設計するか悩みがちです。 　　そこで、実装する際のガイドライン的なものを作成しました。 　　例えば、画面間でどういう風に値を渡すか、画面遷移はどういうにするか。などを決めました。 　　また、現状のアプリ設計を把握できるように簡略化したサンプルアプリの作成もしました。

# 背景 某ECサイトのアプリ版を開発するために業務委託として開発にJoin。 開発体制はネイティブ1人、デザイナー1人、プロデューサー1人。 # やったこと アプリの立ち上げを1人で行った。 受託開発+初めての新規開発アプリということで試行錯誤しながら開発を行なった。 ## アーキテクチャ まず最初に考えたのはどのような設計でアプリを構成するかです。 いままでMVCとMVVMしか業務で採用していませんでした。 当時、MVVM+fluxがトレンドとしてちらほら見る時期だったので、新規開発アプリを実装するなら採用したいと考えました。 そのため、fluxのメリットデメリットを調査しました。ECアプリということで状態の管理が複雑そう、状態変化をちゃんと追いたい。という課題感があったので少し習得に時間がかかるかもと思いましたがメリットには変えられずfluxを採用しました。また運用保守はお客様で行うためfluxのドキュメントも作成して理解できるように努めました。 ## 開発フロー 毎週お客様と定例のミーティングがあり、そこで進捗や要件定義を行いました。 毎週確認してもらうためにビルドするのは大変コストがかかると思ったため、ビルドの自動配布を決まった時間に行うようにしました。自動配布の具体的な方法はbitriseのコマンドでdeploygateに配布することです。そうすることで開発に集中でき、より生産的になれました。