新機能を制作するにあたり、フロントエンドアーキテクチャを検討・議論した過程をまとめました。既存プロジェクトではAtomic Designが多く使われていましたが、今回はせっかくの機会なので新しいアプローチに挑戦することにしました。
前提情報
- 新機能を作成する
- 開発期間は1~2ヶ月
- 開発人数は2名
- どちらもバックエンドエンジニア
- 限られた時間で迷いなく進める必要があった
Atomic Design
結論
不採用
良い点
- デザインの一貫性を保ちやすい
- デザインと開発の連携がスムーズ
悪い点
- MoleculesとOrganismsの境界が曖昧になりやすい
- デザイン原則への理解が浅いと運用が難しい
DDD + Clean Architecture
結論
不採用
良い点
- レイヤー間の受け渡しがI/F経由になる
- テストしやすい
- 保守性・拡張性を高められる
- チーム開発しやすい
悪い点
- ファイル数が多くなる
- 小規模チームではオーバーエンジニアリングになりやすい
Feature-Sliced Design
結論
不採用
良い点
- 世間的に注目が集めている
- 機能単位で独立させられる
- 拡張性が高い
- チーム開発しやすい
悪い点
- 学習コストが高い
- レイヤー＋スライス＋セグメントで分離しているため、小さな組織で活かしきれない
- 習得コストが高く、短期開発には不向きと判断
Bulletproof React
結論
採用
良い点
- 世間的に注目が集めている
- 理論がシンプルであること
- 機能単位でディレクトリを切るので直感的だった
Bulletproof Reactを使った感想
どこにコンポーネントを格納すべきかものすごく簡単だった。コンポーネント、機能で作業分担をしたが、あまりバッティングしなかったのも良かった。また、理論が固まっているため、AIと相性が良かったので副産物で、開発生産性は上げられたと思っている。ただし、小規模な単一機能プロジェクトでは強みを発揮しきれないと感じました。
フロントエンドアーキテクチャを選定した感想
開発人数・期間・スキルレベルに応じて選択できた経験は大きな学びでした。振り返ると、最も重要なのは組織規模や開発体制に合わせることだと感じます。AIとの相性も副次的にプラス要素でしたが、選定理由の決定打ではなく、あくまで補助的な要素にとどまりました。
ぜひみなさんの開発でも参考にしていただければ。
Discussion