レガシーなフロントエンド環境をリプレースするためにチームでやっていること

はじめに

はじめまして！食べログFE（フロントエンド）チームの金野と申します。
普段は、食べログフロントエンドの設計・開発や、新規事業・食べログテイクアウトの技術サポートなどを行っています。

食べログテイクアウトについては、Nuxt.js + TypeScriptの開発について記事を書いているので、興味がある方はぜひ御覧ください。

Nuxt.js+TypeScriptのアプリケーションのためのコーディングガイドライン - Qiita

さて、以前の記事でご紹介したように、食べログFEチームではレガシーシステムのリプレースをReact/TypeScriptで行っています。
今回は、新しいシステムについてもう少し詳しい技術スタックや、どのようなプロセスで開発しているのかを紹介します。

開発効率化のための取り組み

リプレースのお仕事はただひたすら実装するだけではありません。

「壊れにくいアプリケーション」「メンテナビリティが高いアプリケーション」にするために、アーキテクチャや採用する周辺技術について、チームで都度議論したり、開発を効率的に進めるための自動化にも積極的に取り組んでいます。

例えば、新しいシステムでは以下のような取り組みを行っています。

・CI（CircleCI）ではTypeScriptの型チェック、Unit test、lintを実行する。
・Jest + Testing Libraryのカバレッジが80%以下になったらtestが失敗するようにする。
・Jest + StoryShotsでsnapshotテストを行う。
・componentのソースが修正されたら、CIがstorybookのURLをPullRequest上に自動でコメントするようにする。
・OPEN API仕様で記述したAPI定義をSwagger UIでドキュメント化。
・API定義を元に、openapi-generator-cliで型定義含めてapi clientを自動生成する。
・モックAPIとしてPrismを利用する。

このように、様々なツールを利用して品質の担保や開発の効率化を行うのはとてもやりがいがあります。

React/TypeScriptをガリガリ実装するだけではなく、webpack職人をしたり、CircleCIの設定を書いたり、時にはshell scriptを書いたり、やることがたくさんあって嬉しい悲鳴ですね！

CircleCIやshell scriptはフロントエンドエンジニアからすると専門外ではありますが、SREチームなど専門とするメンバーにレビューしてもらえるので安心です。

チームでディスカッションしながら設計する

FEチームでは、全員が設計も開発も両方行っています。「Aさんは設計専門。Bさんは開発専門」のようにはっきりわかれていないということですね。

設計を進めていると、方針に迷うことが度々あります。

「AtomicDesignのルールは？atomsとmoleculesの違いはどう定義する？pagesやtemplate層は必要？」
「Unit testのファイルはどこに置く？コンポーネントのプロダクトコードと同階層に置く？それともrootDir/tests/の中に置く？」
「Unit testやstorybookで使うモックデータ（fixture）はどこに置く？
カスタムhooksとしてまとめる？いっそ別のpackageとして作成する？」
「コンテクスト関連のファイルはどこに置く？ducksパターンにする？しない？」
「サーバーサイドからどこまでデータをもらう？文言はできるだけpresenter層で管理するのが理想だけど…サーバー側でマスタ管理しているデータはどうする？」
「Redux 使う？それともuseContext + useReducer + Portalにする？」

などなど…。

迷ったらMicrosoft Teams上で気軽にスレッドや電話会議を立ち上げて周りを巻き込んでディスカッションします。
その場にいない人がいたら、朝会や夕会の後に共有します。

明文化が必要なものはドキュメントに

議論した結果決まったことはコードに落とし込みますが、すぐに着手できないTODOはJIRAやIssueにタスクとして残しておきます。
新しい規約やルールを決めた際には、lintのルールを追加するなどコードで表現できるものはできるだけそうします。
一方で、コードで縛るのが難しい規約も存在します。明文化したほうがよい規約や、Tipsなどは必要に応じてドキュメントを書きます。

例えば、このようなドキュメントがあります。

Jest + Testing LibraryについてのTipsをまとめたページ：

ディレクトリや規約についてのページ：

※チームでは新しいシステムを「新世界」というコードネームで呼んでおります。

リプレースに伴って出てきた課題についても自分たちで解決する

大規模なリプレースのため、進めていると様々な課題に直面します。

「リプレースの範囲や順序を決めるにあたっては、企画や他チームとも相談が必要だ。」
「プロダクトの機能開発を担っているサーバーサイドエンジニアにも影響のある話になる。マイルストーンや進捗を共有をしよう！」
「SEO要件を満たすための手段も考えよう。Server Side Rendering、Static Site Generation、Dynamic Renderingどれがいいだろう？」
「HTML/CSSを実装するデザイナーさんとも一緒に開発できる環境を整えないと。」

それぞれの課題に対してはチームで向き合い、次のようなプロセスで自分たちで解決に向けて動きます。

・重要度・優先度を明確にする。
・なぜ解決しなければならないのかを明確にする。
・どういう状態になったらゴールなのかを明確にする。
・「いつ」までに「なに」を「どのように」しなければいけないのかを洗い出す。
・洗い出したTodoをJIRAのタスクとして分解する。
・やるべきことを実行する。

デザイナーさんと一緒に開発できる環境を整えたときは

一例を紹介します。

良いプロダクトを作るためには他のチームとの協働は必要不可欠です。
食べログでは、デザイナーさんがlook and feel（外観と操作感）の部分に責任を持っているため、デザイナーさんもHTML/CSSの実装を行います。

従来のRails + SCSSからReact + styled-componentsに移行するにあたり、デザイナーさんにも技術共有を行うことが必要でした。
この課題に対しては、以下の施策を実施しました。

1.  新しいシステムでは、FEとデザイナーで実装をどう分担するかデザインチームの部長やリーダーと相談
2.  リプレースや技術共有のマイルストーンをデザインチームに共有
3.  Atomic Designについての勉強会を実施
　- "Atomic Designとはなにか"と、食べログでのルール
4.  新しいシステムの概要や技術スタックについて共有
　- 従来のRails + ES6 + SCSSと大きく異なる点は？
　- Reactとは？TypeScriptとは？storybookとは？
5.  styled-componentsとJSXについての勉強会を実施
　- styled-componentsの特徴や注意点
6.  styled-componentsの規約についての説明会を実施
7.  新システムを担当するデザイナーさんとペアプロを実施
　- JSXとstyled-components の簡単な実装を一緒に行う。
　- SublimeからVSCodeに乗り換えてもらうためのガイドも提供

実は、「5. styled-componentsとJSXについての勉強会」の前には「CSS Modulesについての勉強会」と「CSS Modulesの規約の説明会」もありました。

…が、その後CSS Modulesがメンテナンスオンリーになったことが判明したためstyled-componentsに乗り換えたという経緯があります。

以下はデザイナーさんとペアプロをするにあたって作成したドキュメントです。

技術顧問について

FEチームには、業務でのReact/TypeScriptの開発経験がないメンバーも多いので、方針について迷うことが多々あります。

ですが、食べログFEチームには技術顧問としてwebpackやNode.jsのcommitterである@hiroppyさんが参画しています。
方針に迷ったときに相談に乗ってくれたり、コードをレビューしてくれたり、ペアプロをしてくれたり、React周辺の最新情報やベストプラクティスの共有をしてくれたりとサポートしていただいています！

最後に

今回触れた技術や取り組みについては、今後このブログで詳しい内容を紹介していきたいなと思っています。

また、食べログでは、一緒にリプレースに取り組んでくれる仲間を大募集中です！

・React/TypeScriptでバリバリ開発したい
・大規模なアプリケーション開発に挑戦したい
・レガシーなシステムのリファクタリングがしたい
・フロントエンド周りの自動化に取り組みたい
・アーキテクチャについて探求したい
・食べログというプロダクトに貢献したい

どれかに当てはまった方は以下のリンクを是非御覧ください！