Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 やなぎ（24歳） PR TIMES 開発本部 フロントエンドエンジニア - 新卒3年目 - 一児のパパ

Slide 3

Slide 3 text

会社名 株式会社PR TIMES 所在地 東京都港区赤坂一丁目11番44号 設立日 2005年12月26日（16期目） 資本金 4億2066万円 代表者 代表取締役社長 山口 拓己 従業員数 約250名（正社員135名※グルコース含む） 会社概要

Slide 4

Slide 4 text

Product｜基幹事業 プレスリリース配信サービスを運営 企業の一次情報が日本で最も集まるプラットフォームとして、国内トップシェア ● 利用企業社数 ● 国内上場企業利用率 ● プレスリリース数 ● メディアユーザー数 ● パートナーメディア ● サイト閲覧数 ● SNSアカウント ● 個人ユーザー数 83,548社 54.5％ 33,801件 / 月 25,562名 234媒体 7,597万PV / 月 Facebook 128,949 Twitter 456,987 174,997名

Slide 5

Slide 5 text

フロントエンド開発の速度を上げるための取り組み - ページ単位でのReactリプレイス - MonorepoによるDesign Systemの配布 - Feature Flagの活用

Slide 6

Slide 6 text

ページ単位でのReactリプレイス

Slide 7

Slide 7 text

ページ単位でのReactリプレイス リプレイス戦略 - 機能追加を行うページをリプレイスしてから機能追加を行う

Slide 8

Slide 8 text

ページ単位でのReactリプレイス 最初にReactにリプレイスしたページ

Slide 9

Slide 9 text

ページ単位でのReactリプレイス Reactにリプレイスしてからプレスキット機能を追加

Slide 10

Slide 10 text

ページ単位でのReactリプレイス 旧技術スタック - jQuery - JavaScript (ES5以前) - JavaScript (ES6以降) - Vue.js - SCSS

Slide 11

Slide 11 text

ページ単位でのReactリプレイス 問題点 - 1つページだけでもこれらの技術が使われておりカオス - ドキュメントなどがなくどこに何が書いてあるのか不明 - ディレクトリ構造のルールが不明

Slide 12

Slide 12 text

ページ単位でのReactリプレイス 問題点 - 1つページだけでもこれらの技術が使われておりカオス - ドキュメントなどがなくどこに何が書いてあるのか不明 - ディレクトリ構造のルールが不明 コードのキャッチアップが大変 手を加えるとバグが発生しやすい

Slide 13

Slide 13 text

ページ単位でのReactリプレイス 旧技術スタック - jQuery - JavaScript (ES5以前) - JavaScript (ES6以降) - Vue.js - SCSS 新技術スタック - React - TypeScript - Emotion - TanStack Query - Recoil

Slide 14

Slide 14 text

ページ単位でのReactリプレイス リプレイス後 - 使用する技術がReact/TypeScriptに統一できた - 技術の選定理由や意思決定をnotionに記載するようにした - ディレクトリの切り方をドキュメント化

Slide 15

Slide 15 text

ページ単位でのReactリプレイス リプレイス後 - 使用する技術がReact/TypeScriptに統一できた - 技術の選定理由や意思決定をnotionに記載するようにした - ディレクトリの切り方をドキュメント化 コードのキャッチアップが容易になり 開発速度が向上した

Slide 16

Slide 16 text

MonorepoによるDesign Systemの配布

Slide 17

Slide 17 text

複数のサービス/アプリケーションを運用・開発 MonorepoによるDesign Systemの配布 プレスリリース配信サービス 「PR TIMES」 広報・PRの効果測定サービス 「PR TIMES Webクリッピング」 企業管理画面

Slide 18

Slide 18 text

Design Systemによるデザインの統一・コンポーネントの再利用 MonorepoによるDesign Systemの配布

Slide 19

Slide 19 text

Design Systemの配布方法 - Monorepo vs Multi Repo MonorepoによるDesign Systemの配布

Slide 20

Slide 20 text

Monorepo vs Multi Repo - PR TIMESのフロントエンドメンバーは4人（当時） - Multi Repoにするとオーナーが存在しないRepositoryができそう - packageを運用した経験があるメンバーがいない - releaseやversion管理がよく分からない - private packageにする必要があり認証が煩雑になる MonorepoによるDesign Systemの配布

Slide 21

Slide 21 text

Monorepoを採用 - 導入の手軽さや運用・管理を考え、Monorepoを採用 - yarn workspaceを用いた - 現在は pnpm workspace に移行 MonorepoによるDesign Systemの配布

Slide 22

Slide 22 text

恩恵 - Monorepoを用いたことによる運用・管理のコスト軽減 - コンポーネントの再利用性の向上 MonorepoによるDesign Systemの配布

Slide 23

Slide 23 text

恩恵 - Monorepoを用いたことによる運用・管理のコスト軽減 - コンポーネントの再利用性の向上 MonorepoによるDesign Systemの配布 車輪の再発明、些細なデザインの差異による実装の増加がなくなり 開発速度が向上した

Slide 24

Slide 24 text

Feature Flagの活用

Slide 25

Slide 25 text

Feature Flagの活用 Feature Flagとは export const FeaturePage = () => { return (

Feature Page

{FeatureFlag ? : }
); };

Slide 26

Slide 26 text

Feature Flagの活用 変更のリードタイムの削減 - 開発速度だけが上がってもPull Requestをマージできないと意味がない - 細かい変更を頻繁にマージする - 変更量が多いとレビュー速度の低下・手戻りコストの増大に繋がる

Slide 27

Slide 27 text

Feature Flagの活用 変更のリードタイムの削減 - 開発速度だけが上がってもPull Requestをマージできないと意味がない - 細かい変更を頻繁にマージする - 変更量が多いとレビュー速度の低下・手戻りコストの増大に繋がる Feature Flagを活用することで 機能が未完成でもマージすることができる

Slide 28

Slide 28 text

これらの取り組みにより ※ バックエンド関連のPull Requestも含んでいます🙏 引用：https://speakerdeck.com/meihei3/phpcon2022-e259c9cb-1462-4e0a-b22c-20327532bbee?slide=23

Slide 29

Slide 29 text

開発速度は向上したが、品質の担保はどうなの？

Slide 30

Slide 30 text

品質を保つための取り組み - XOによるコーディングルールの統一 - Unit/Integration Testの拡充 - Visual Regression TestによるUI崩れの検知

Slide 31

Slide 31 text

XOによるコーディングルールの統一

Slide 32

Slide 32 text

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翻訳）

Slide 33

Slide 33 text

XOによるコーディングルールの統一 選定理由 - 自前でルールセットを作ると議論することが多い - 各Pluginのバージョンアップをする必要がある - eslint-config-airbnbやeslint-config-googleなどのルールセットは直近 でメンテナンスされていない（eslint-config-googleはアーカイブ済み） - XOはメンテナンスが継続的にされており、ルールセットがかなり厳しい

Slide 34

Slide 34 text

XOによるコーディングルールの統一 恩恵 - コーディングルールの運用コストが減った - 多数のlintルールを含んでいるため記法を厳格に矯正される - 細かい部分までルール化されるため書き方を迷わなくなった

Slide 35

Slide 35 text

XOによるコーディングルールの統一 恩恵 - コーディングルールの運用コストが減った - 多数のlintルールを含んでいるため記法を厳格に矯正される - 細かい部分までルール化されるため書き方を迷わなくなった 統一性のあるコードとなった 迷いがなくなったことにより開発速度が向上

Slide 36

Slide 36 text

Unit/Integration Testの拡充

Slide 37

Slide 37 text

Unit/Integration Testの拡充 Reactリプレイスを始める前のフロントエンドテスト事情 - テストが1つもない - そもそもテストツールが入ってない - そもそもテストが書けるコードではない - jQuery, JavaScript（ES5, ES6）, Vue.js, Scssが混在していたため

Slide 38

Slide 38 text

Unit/Integration Testの拡充 テスト文化が芽生え始めた！ https://developers.prtimes.jp/2022/10/31/tdd-workshop-2022/

Slide 39

Slide 39 text

Unit/Integration Testの拡充 TDDワークショップを行ったことにより - QA任せだった品質担保をエンジニアでも考えるようになった - テストの書き方・考え方がわかった - テスト文化が芽生えた - 今ではテストを書くのが当たり前になった

Slide 40

Slide 40 text

Unit/Integration Testの拡充 現在のフロントエンドテスト事情 - Unit Testのテスト数 3000 Over - Integration Testのテスト数 100 Over

Slide 41

Slide 41 text

Unit/Integration Testの拡充 使用しているツール Unit Test - Vitest, React Testing Library, JSDom, MSW, storybook/testing-library Integration Test - Playwright（API Fetchはinterceptでmock）

Slide 42

Slide 42 text

Visual Regression TestによるUI崩れの検知

Slide 43

Slide 43 text

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');
 });


Slide 44

Slide 44 text

Visual Regression TestによるUI崩れの検知 snapshotの管理 - 今のところGitで管理している - 純粋にPlaywright単体でVRTができ、フローが簡潔になる - GitHubのFiles changedで差分を確認できる

Slide 45

Slide 45 text

Visual Regression TestによるUI崩れの検知 Visual Regression Testのフロー

Slide 46

Slide 46 text

Visual Regression TestによるUI崩れの検知 Files changedでの差分確認

Slide 47

Slide 47 text

Visual Regression TestによるUI崩れの検知 Files changedでの差分確認

Slide 48

Slide 48 text

まとめ 開発速度向上の取り組み - Reactリプレイス - Design System - Feature Flag 品質担保の取り組み - XOによる厳格なコーディング規約 - Unit/Integration Testの拡充 - Visual Regression Test