3月8日にリクルートで開催された RECRUIT Technologies NIGHT vol.5 リクルート流フロントエンド開発 に行ってきました。
イベント概要
イベントページから引用しました。
大規模サービスを複数抱えるリクルート。そのフロントエンド開発はどのように行われ、改革されてきたのか。そしてどんな姿を目指しているのか。 現場のフロントエンドエンジニアが、リアルな開発秘話をお届けします。
参加動機
- RECRUIT Technologies NIGHT にこれまで参加したことはなかったが、今回の講演に React Native に関する内容があったため
- React や React Native はまだチュートリアルをやった程度で講演の内容的に多少場違いかなと思いつつ、今後のために知っておくべきキーワードを知りたかった
React / Redux を活用したリクルートテクノロジーズのフロントエンド開発
リクルートのWeb
- 予約サイトは一覧ページだけではなく、詳細ページに直でアクセスするユーザーが多い( URLをシェアされることが多い )
- => 一覧ページと詳細ページ、両方のパフォーマンスが重要
- Nativeアプリっぽさ、インタラクティブな動きが求められる
- 要望を満たすにはこれまで通りの仕組みでは厳しい
- => React x Redux x Node.js により自社製フレームワークの開発
サーバーでもクライアントでもレンダリングする
- 話は WEB DB+ を読むのが早い
- 初期表示の改善に効果がある( OGP や SEO などの対応がしやすい )
- 検索中など回遊中のユーザーの UX も、初期表示の速度も改善できる
- ただし、今のReactのサーバーサイドレンダリングは重い、そしてこの処理は非同期ではない
- 回避方法、レンダリング結果をキャッシュする等々
History を壊さない
History.back()を行った時、スクロール位置が復元されない( Twitter のような無限スクロールのサイトなど)- 原因はHTMLが復元されていない状態で戻ってしまうこと( ブラウザは覚えている けど、レンダリングされていないため )
- => 回避策、再リクエストが走っている間はレンダリングさせない、レスポンスが返ってきてからレンダリングさせる
Consumer Drive Contractで開発する
- APIの仕様をバックエンド( Provider )が決めるのではなく、フロントエンド( Consumer )が主導して要求を書くというスタイルの仕様策定方法
- 記述したファイルをモックにして、テストを行うなどテストツールにもなる
- ただし、 コミュニケーションコストは安くない 、より密にコミュニケーションを取る必要がある！
フロントエンドエンジニアが React Native を触ってみた話
React Native について
- Web 技術で iOS / Android アプリの開発ができる
- ハイパフォーマンス
- 開発効率が良い( Live Reload, Hot Reloading )
- Live Reload … 値がリセットされる(初期画面に戻る)
- Hot Reloading … ステートの状態を保持するので値は変わらない(ページトップに戻らずに更新ができる)
- Learn Once, Write Anywhere!
- React Native for Windows や React Native for MacOS によりデスクトップアプリの開発もできる
- iOS と Android でそれぞれに特化したコードを書く必要があるが、コードは共有できる
React と ReactNative の違い
- だいたいそのまま使える( Web タグから JSX による実装 )
- CSs in JS
iOSとAndroidの違い
- OS により UI / UX のベストプラクティスが違う(ハンバーガーメニュー/タブメニューなど)
- OS 別にファイルを分けて書く方法はあるし、コード中での if 文による分岐も問題ない
- ビルド時にOSを指定してビルドすることもできる
なぜ React Native なのか
- Web 版で開発したコードの共有化が可能
- WebView を React Native 化することでパフォーマンス向上が狙える
デモアプリを作ってみての感想
- WebのReactを知っていればすぐにできる( Web に近い感覚での開発)
- React からだと画面は作り直す必要がある(要素は全部違う)、構造などは参考にできる
- 共通化できるコードも多いので、Webもスマホもということができる
- Objective-C 、 Java の知識が必須というわけではない(実現したい内容によっては必要)
リクルートのフロントエンド変革に挑んだ話
これまで
- フロントエンドとバックエンドで開発チームが分かれていて、フロントエンドチームが開発したコードをバックエンドチームでマージして取り込んでいた
- フロントエンドが View を見れる状態になく、CSS の影響度調査をすることができない
- マージ時にバックエンドチームが修正した内容がフロンとエンドに伝わらないため、デグレが頻発
どう突破したか
- 人はメリットがないと動かない
- フロー変革による障害リスクなど、デメリットを上回るメリットを求められる
- バックエンド経験のあるフロントエンドエンジニア
- JSにロジックがあり、必要に応じてバックエンドに聞くなどのコミュニケーションコスト
- 環境構築などで対応する必要がある -> バックエンド経験のあるエンジニアがいればコスト短縮できる
- 何かあったら元のやり方に戻すことを決定するなど、心理的ハードルを下げる
現在
- 90% が View のコードを書いている、開発工数 25% 削減
- 影響範囲がわかるようになったので、リファクタリングもできる
- フロントエンド経験のある人、バックエンド経験のある人たちで互いに補う
- しかし、フロントエンドエンジニアがバックエンドを学ぶにはハードルが高い( 改善すべき点が多かった反省 )
行ってみた感想
- 「フロントエンドエンジニアが React Native を触ってみた話」では実際のコードについての解説があったが、理解できない部分が多かった
- 「フロントエンドエンジニア」の定義を実はあまり理解していなかったが、バナーなどのデザインからマークアップ、React Native のような JavaScript コードを書く人を指すなど幅広いことを改めて認識した
- 理解の乏しいものや、分からないキーワードが大変多かった
- FlexBox, Redux, Java Script Core, JS Runtime, Bridge, Data Flow, Live Reload, Hot Reloading
