Bulletproof Reactで始める！ESLintで強化する！効果的なプロダクト開発

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Yusuke Ishimi 株式会社プレックス SaaS事業の立ち上げやっています X : @naro143 🐱: @naro143

Slide 3

Slide 3 text

時間が足りない

Slide 4

Slide 4 text

関心事を分けると開発は早くなる

Slide 5

Slide 5 text

Bulletproof React

Slide 6

Slide 6 text

React Appのアーキテクチャ説明と具体例があり非常に良い。 https://github.com/alan2207/bulletproof-react

Slide 7

Slide 7 text

Project Structure

Slide 8

Slide 8 text

大事な箇所だけ、さくっと見ます

Slide 9

Slide 9 text

features

Slide 10

Slide 10 text

大事な箇所だけ、さくっと見ます

Slide 11

Slide 11 text

導入してみた

Slide 12

Slide 12 text

前提 ● SaaS事業の立ち上げ期 ● 正式リリースに向けてデザインリニューアルをするタイミングで導入 ● Next.js 13のプロジェクトに導入特性 ● 市場・顧客の知識が複雑 ● 機能の正解がわからない ● 副業メンバー多数での開発

Slide 13

Slide 13 text

シンプルな方針 1つのroutingに対して1つのfeaturesとした。理由は後述。 ● src/app/projects ● src/features/projects ● src/app/projects/[projectId] ● src/features/project-detail

Slide 14

Slide 14 text

こんな感じ ▼page.tsx 　　features/ ▶

Slide 15

Slide 15 text

良かったこと ● 「どこに実装するか？汎用的に実装するか？」で悩む時間が少なくなった。 ○ プロダクト初期では「同じ UIだけど、同じ責務か？」の判断が難しい。（◀ 方針の理由） ○ 個人的には「不毛な実装しているな」と感じるまでは共通化はしなくて良いと考えている。 ● 影響範囲がfeatures内に閉じるため、考慮事項が少なくなった。 ○ 副業メンバーなど深く事業に関わらないメンバーがより成果を出せるようになった。 ○ 挑戦とフィードバックの質が上がり、メンバーの成長が早くなった。 ● 構成の指針があることで、自然と責務の分離がされるようになった。

Slide 16

Slide 16 text

featuresの導入によって、関心事が分かれて開発が早くなった✨

Slide 17

Slide 17 text

ESLint

Slide 18

Slide 18 text

依存関係を制限する ● features/ は他のfeaturesを参照しない ● components/ はfeaturesを参照しない ● lib/ はfeaturesを参照しない ● providers/ はfeaturesを参照しない

Slide 19

Slide 19 text

index.tsでexportしたものだけ許可する features内は ../ で参照できる。