iOSエンジニアが2年弱ぶりにフロントエンド開発をやってみて感じたこと

この度、株式会社Pathee のエンジニアブログをはじめました。

「エンジニアブログ」とは言うものの、DevOpsの文脈で語られるITバリューストリームに照らし合わせれば、弊社のあらゆる人々はエンジニアということになりますので、Patheeの社員が話題を限らずに各自の興味範囲を書き起こしていく場としていきたいと思います。

ご挨拶が遅れました。はじめまして、Pathee パートナーエンジニアの @keisei1092 です。

Pathee パートナー（※）で主にフロントエンドを担当しつつ、適時API側も開発しています。

※ 小売店舗向けデジタルマーケティング支援SaaS

Patheeに今年1月に入社する前は、前々職でPHP, Ruby on RailsでWebアプリケーションを書いた後iOSアプリを担当し、前職でも主にiOSアプリを担当していました。Patheeでは現行で開発しているiOSアプリはなく、既存のWebアプリケーション開発からジョインすることにしました。

iOSアプリケーションなどのネイティブアプリケーション開発とWebアプリケーション開発には、インストールや審査の有無、乗っているプラットフォームの違いなどがあり、開発、テスト、運用手法に大きく乖離が生まれることになります。

私は2年弱ほどiOSアプリケーションの開発に従事していたため、Webアプリケーション開発の現場に入ってみていくつか感じたことがありました。今回は主にこのことについて書いていきたいと思いますので、主に近い境遇の方に読んで頂ければ幸いです。

ReactとReduxについて

iOSの現場にいても、 React と Redux (Flux) はモダンなフロントエンドでほぼほぼ必ず使われているという認識はありました。

iOSアプリケーション開発は UIKit に則ったコンポーネント指向の開発ができるようになっており、 React のコンポーネント指向や、 componentDidMount をはじめとしたライフサイクルにも問題なく馴染むことができました。コンポーネント単位でディレクトリやファイルが分割されていることで、編集すべき箇所もわかりやすいですし、grepのし易さも向上しているなと思いました。

どちらかといえば、久しぶりに対峙したCSSに対するアレルギーが抜けていないことが玉に瑕でしょうか・・・。Pathee パートナーのCSSには Flocss と BEM を合わせたような命名規則を採用しており、セレクタを一目見ただけでだいたいの責務がわかるようになっています。iOSのAutoLayoutはビジュアルで操作できた楽しさがあった反面、CSSはコードでの編集となるぶん地味ではありますが、Webpackのhot reloadのおかげでブラウザを開きながらの即時反映でより感覚的にできるようになっているなと感じました。

iOSでは Human Interface Guidelines とよばれる詳細なデザインガイドラインが存在し、「ボタンの高さは44px以上の指で押しやすいものを」「ナビゲーションにはUINavigationBarやUITabBarを使う」などiOS開発者やデザイナーに共通の言語と認識がありました。Reactにはそのようなものはありませんので、チームごとに共通認識を築いていく必要があります。

次にデータのやり取りに関してですが、私がiOSアプリケーション開発の現場で最も長く取り組んでいた設計はRxSwiftを用いたMVVMアーキテクチャでした。

Pathee パートナーではデータをやり取りするためのパターンとして Redux を採用しています。MVVMパターンではViewに対してViewModelがつき、Modelから得た値をbindするというのが基本ですが、ReduxではViewはStateの値をrenderしてユーザのイベントに従ってActionを呼ぶだけで、reducerやmiddlewareがビジネスロジックや永続化を担います。このパターンのキャッチアップが若干難しかったのですが、iOSのMVVMの知識を流用して「MVVMでよく書いてたあのロジックはReduxのここなのか」「Repositoryはなくて、operation層（※）というのがあるんだな」という感じで理解していくことができています。

※ redux-saga を使ってAPIとやり取りする責務を担っている

テストについて

Redux は個々のコンポーネントに対してのテストが非常に書きやすいと感じました。

iOSアプリケーション開発では往々にして単体テストなどがおざなりになっており、リリース前の品質確認（QA）でカバーするような風習があると感じていました。確かにObjective-CやSwiftでは型付けが強力なため頑丈なコードを書いていくことができますが、継続的に「（...テスト書いた方がいいんじゃないかなぁ？）」というような思いは抱いていました。ReactとRedux（と、middleware）のパターンでは責任の分界点がとても明確で、それぞれの責務が小さいため、どのコンポーネントに対しても少ないコストで単体テストを書くことができると感じました。またテスティングフレームワークの jest と支援ツールの enzyme が非常に強力なため、どのコンポーネントに対しても最小のコード量で要件に見合ったテストコードを作成することができます。リファクタリングやフィーチャーブランチを作った際にしょっちゅうテストケースをこけさせてしまうので、既存コードやコーディングのポリシーのキャッチアップにも効果があり、大変便利だと感じています。

テストカバレッジをどれだけ目指していくかなどはまだチーム内で話し切れていないので、フロントエンド開発の現状のデファクトを調査しながらも、建設的なテストができていけるようにしていきたいと思います。

運用について

iOSアプリケーションはリリースやバージョンアップに審査を伴うため、リリースにかける体力が必要と感じていました。フロントエンドではリリースはコードの変更を本番環境に反映することが主な作業で、待ち時間やプロダクトの制約なしにリリースができる点は魅力的に映ります。

ただブラウザ間差異があることはiOSのデバイス間差異と同じく留意しなければいけません。自分が実装したページがIE11で開くと真っ白になるという報告をもらった時は冷や汗をかきました。ブラウザがサポートしている／いないJavaScriptのクラスやメソッドなどの知識がないとこのようなことを引き起こすので、これからデプロイ前に注意していきたいと思います。