開発速度を上げつつ品質を保つためのフロントエンド開発

PR TIMESで行なっている開発速度向上と品質担保のためにやっているフロントエンド開発の取り組みについてご紹介します。

Transcript

1. 開発速度を上げつつ品質を保つための フロントエンド開発
2. 自己紹介 やなぎ（24歳） PR TIMES 開発本部 フロントエンドエンジニア - 新卒3年目 - 一児のパパ
3. 会社名 株式会社PR TIMES 所在地 東京都港区赤坂一丁目11番44号 設立日 2005年12月26日（16期目） 資本金 4億2066万円 代表者 代表取締役社長 山口 拓己 従業員数 約250名（正社員135名※グルコース含む） 会社概要
4. Product｜基幹事業 プレスリリース配信サービスを運営 企業の一次情報が日本で最も集まるプラットフォームとして、国内トップシェア • 利用企業社数 • 国内上場企業利用率 • プレスリリース数 • メディアユーザー数 • パートナーメディア • サイト閲覧数 • SNSアカウント • 個人ユーザー数 83,548社 54.5％ 33,801件 / 月 25,562名 234媒体 7,597万PV / 月 Facebook 128,949 Twitter 456,987 174,997名
5. フロントエンド開発の速度を上げるための取り組み - ページ単位でのReactリプレイス - MonorepoによるDesign Systemの配布 - Feature Flagの活用
6. ページ単位でのReactリプレイス
7. ページ単位でのReactリプレイス リプレイス戦略 - 機能追加を行うページをリプレイスしてから機能追加を行う
8. ページ単位でのReactリプレイス 最初にReactにリプレイスしたページ
9. ページ単位でのReactリプレイス Reactにリプレイスしてからプレスキット機能を追加
10. ページ単位でのReactリプレイス 旧技術スタック - jQuery - JavaScript (ES5以前) - JavaScript (ES6以降) - Vue.js - SCSS
11. ページ単位でのReactリプレイス 問題点 - 1つページだけでもこれらの技術が使われておりカオス - ドキュメントなどがなくどこに何が書いてあるのか不明 - ディレクトリ構造のルールが不明
12. ページ単位でのReactリプレイス 問題点 - 1つページだけでもこれらの技術が使われておりカオス - ドキュメントなどがなくどこに何が書いてあるのか不明 - ディレクトリ構造のルールが不明 コードのキャッチアップが大変 手を加えるとバグが発生しやすい
13. ページ単位でのReactリプレイス 旧技術スタック - jQuery - JavaScript (ES5以前) - JavaScript (ES6以降) - Vue.js - SCSS 新技術スタック - React - TypeScript - Emotion - TanStack Query - Recoil
14. ページ単位でのReactリプレイス リプレイス後 - 使用する技術がReact/TypeScriptに統一できた - 技術の選定理由や意思決定をnotionに記載するようにした - ディレクトリの切り方をドキュメント化
15. ページ単位でのReactリプレイス リプレイス後 - 使用する技術がReact/TypeScriptに統一できた - 技術の選定理由や意思決定をnotionに記載するようにした - ディレクトリの切り方をドキュメント化 コードのキャッチアップが容易になり 開発速度が向上した
16. MonorepoによるDesign Systemの配布
17. 複数のサービス/アプリケーションを運用・開発 MonorepoによるDesign Systemの配布 プレスリリース配信サービス 「PR TIMES」 広報・PRの効果測定サービス 「PR TIMES Webクリッピング」 企業管理画面
18. Design Systemによるデザインの統一・コンポーネントの再利用 MonorepoによるDesign Systemの配布
19. Design Systemの配布方法 - Monorepo vs Multi Repo MonorepoによるDesign Systemの配布
20. Monorepo vs Multi Repo - PR TIMESのフロントエンドメンバーは4人（当時） - Multi Repoにするとオーナーが存在しないRepositoryができそう - packageを運用した経験があるメンバーがいない - releaseやversion管理がよく分からない - private packageにする必要があり認証が煩雑になる MonorepoによるDesign Systemの配布
21. Monorepoを採用 - 導入の手軽さや運用・管理を考え、Monorepoを採用 - yarn workspaceを用いた - 現在は pnpm workspace に移行 MonorepoによるDesign Systemの配布
22. 恩恵 - Monorepoを用いたことによる運用・管理のコスト軽減 - コンポーネントの再利用性の向上 MonorepoによるDesign Systemの配布
23. 恩恵 - Monorepoを用いたことによる運用・管理のコスト軽減 - コンポーネントの再利用性の向上 MonorepoによるDesign Systemの配布 車輪の再発明、些細なデザインの差異による実装の増加がなくなり 開発速度が向上した
24. Feature Flagの活用
25. Feature Flagの活用 Feature Flagとは export const FeaturePage = () => { return ( <div> <h1>Feature Page</h1> {FeatureFlag ? <NewFeatureComponent /> : <OldFeatureComponent />} </div> ); };
26. Feature Flagの活用 変更のリードタイムの削減 - 開発速度だけが上がってもPull Requestをマージできないと意味がない - 細かい変更を頻繁にマージする - 変更量が多いとレビュー速度の低下・手戻りコストの増大に繋がる
27. Feature Flagの活用 変更のリードタイムの削減 - 開発速度だけが上がってもPull Requestをマージできないと意味がない - 細かい変更を頻繁にマージする - 変更量が多いとレビュー速度の低下・手戻りコストの増大に繋がる Feature Flagを活用することで 機能が未完成でもマージすることができる
28. これらの取り組みにより ※ バックエンド関連のPull Requestも含んでいます🙏 引用：https://speakerdeck.com/meihei3/phpcon2022-e259c9cb-1462-4e0a-b22c-20327532bbee?slide=23
29. 開発速度は向上したが、品質の担保はどうなの？
30. 品質を保つための取り組み - XOによるコーディングルールの統一 - Unit/Integration Testの拡充 - Visual Regression TestによるUI崩れの検知
31. XOによるコーディングルールの統一
32. XOによるコーディングルールの統一 XO（https://github.com/xojs/xo） とは Opinionated but configurable ESLint wrapper with lots of goodies included. Enforces strict and readable code. Never discuss code style on a pull request again! No decision-making. No .eslintrc to manage. It just works! 意見が多いが設定可能なESLintラッパー。厳密で読みやすいコードを強制します。 もうプルリクエストでコードスタイルを議論する必要はありません！意思決定不 要。.eslintrcを管理する必要もありません。ただ動くだけです！ （DeepL翻訳）
33. XOによるコーディングルールの統一 選定理由 - 自前でルールセットを作ると議論することが多い - 各Pluginのバージョンアップをする必要がある - eslint-config-airbnbやeslint-config-googleなどのルールセットは直近 でメンテナンスされていない（eslint-config-googleはアーカイブ済み） - XOはメンテナンスが継続的にされており、ルールセットがかなり厳しい
34. XOによるコーディングルールの統一 恩恵 - コーディングルールの運用コストが減った - 多数のlintルールを含んでいるため記法を厳格に矯正される - 細かい部分までルール化されるため書き方を迷わなくなった
35. XOによるコーディングルールの統一 恩恵 - コーディングルールの運用コストが減った - 多数のlintルールを含んでいるため記法を厳格に矯正される - 細かい部分までルール化されるため書き方を迷わなくなった 統一性のあるコードとなった 迷いがなくなったことにより開発速度が向上
36. Unit/Integration Testの拡充
37. Unit/Integration Testの拡充 Reactリプレイスを始める前のフロントエンドテスト事情 - テストが1つもない - そもそもテストツールが入ってない - そもそもテストが書けるコードではない - jQuery, JavaScript（ES5, ES6）, Vue.js, Scssが混在していたため
38. Unit/Integration Testの拡充 テスト文化が芽生え始めた！ https://developers.prtimes.jp/2022/10/31/tdd-workshop-2022/
39. Unit/Integration Testの拡充 TDDワークショップを行ったことにより - QA任せだった品質担保をエンジニアでも考えるようになった - テストの書き方・考え方がわかった - テスト文化が芽生えた - 今ではテストを書くのが当たり前になった
40. Unit/Integration Testの拡充 現在のフロントエンドテスト事情 - Unit Testのテスト数 3000 Over - Integration Testのテスト数 100 Over
41. Unit/Integration Testの拡充 使用しているツール Unit Test - Vitest, React Testing Library, JSDom, MSW, storybook/testing-library Integration Test - Playwright（API Fetchはinterceptでmock）
42. Visual Regression TestによるUI崩れの検知
43. Visual Regression TestによるUI崩れの検知 Playwright単体でのVisual Regression Test test('VRT', async ({ page }) => {
 await page.goto('/');
 // タイトルという文言が表示されているか確認する
 await expect(page.getByText('タイトル')).toBeVisible();
 // VRT
 await expect(page).toHaveScreenshot('VRT.png');
 });

44. Visual Regression TestによるUI崩れの検知 snapshotの管理 - 今のところGitで管理している - 純粋にPlaywright単体でVRTができ、フローが簡潔になる - GitHubのFiles changedで差分を確認できる
45. Visual Regression TestによるUI崩れの検知 Visual Regression Testのフロー
46. Visual Regression TestによるUI崩れの検知 Files changedでの差分確認
47. Visual Regression TestによるUI崩れの検知 Files changedでの差分確認
48. まとめ 開発速度向上の取り組み - Reactリプレイス - Design System - Feature Flag 品質担保の取り組み - XOによる厳格なコーディング規約 - Unit/Integration Testの拡充 - Visual Regression Test