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

# 参考資料
https://github.com/alan2207/bulletproof-react

Transcript

1. Bulletproof Reactで始める！ESLintで強化する！ 効果的なプロダクト開発
2. Yusuke Ishimi 株式会社プレックス SaaS事業の立ち上げやっています X : @naro143 🐱: @naro143
3. 時間が足りない
4. 関心事を分けると開発は早くなる
5. Bulletproof React
6. React Appのアーキテクチャ 説明と具体例があり非常に良い。 https://github.com/alan2207/bulletproof-react
7. Project Structure
8. 大事な箇所だけ、さくっと見ます
9. features
10. 大事な箇所だけ、さくっと見ます
11. 導入してみた
12. 前提 • SaaS事業の立ち上げ期 • 正式リリースに向けてデザインリニューアルをするタイミングで導入 • Next.js 13のプロジェクトに導入 特性 • 市場・顧客の知識が複雑 • 機能の正解がわからない • 副業メンバー多数での開発
13. シンプルな方針 1つのroutingに対して1つのfeaturesとした。理由は後述。 • src/app/projects • src/features/projects • src/app/projects/[projectId] • src/features/project-detail
14. こんな感じ ▼page.tsx 　　features/ ▶
15. 良かったこと • 「どこに実装するか？汎用的に実装するか？」で悩む時間が少なくなった。 ◦ プロダクト初期では「同じ UIだけど、同じ責務か？」の判断が難しい。（◀ 方針の理由） ◦ 個人的には「不毛な実装しているな」と感じるまでは共通化はしなくて良いと考えている。 • 影響範囲がfeatures内に閉じるため、考慮事項が少なくなった。 ◦ 副業メンバーなど深く事業に関わらないメンバーがより成果を出せるようになった。 ◦ 挑戦とフィードバックの質が上がり、メンバーの成長が早くなった。 • 構成の指針があることで、自然と責務の分離がされるようになった。
16. featuresの導入によって、 関心事が分かれて開発が早くなった✨
17. ESLint
18. 依存関係を制限する • features/ は他のfeaturesを参照しない • components/ はfeaturesを参照しない • lib/ はfeaturesを参照しない • providers/ はfeaturesを参照しない
19. index.tsでexportしたものだけ許可する features内は ../ で参照できる。
20. まだ語りたいけど...!
21. ここまで！
22. 参考 • https://github.com/alan2207/bulletproof-react