モチベーション
Feature-Sliced Designの主なアイデアは、さまざまな開発者の経験を議論し、研究結果を統合することに基づいて、複雑で発展するプロジェクトの開発を容易にし、開発コストを削減することです。
明らかに、これは銀の弾丸ではなく、当然ながら、FSDには独自の適用範囲の限界があります。
既存の解決策が不足している理由
通常、次のような議論があります。
- 「SOLID」、「KISS」、「YAGNI」、「DDD」、「GRASP」、「DRY」など、すでに確立された設計原則があるのに、なぜ新しい方法論が必要なのか？」
- 「プロジェクトのすべての問題は、良いドキュメント、テスト、確立されたプロセスで解決できる」
- 「すべての問題は、すべての開発者が上記のすべてに従えば解決される」
- 「すでにすべてが考案されているから、あなたはそれを利用できないだけだ」
- {FRAMEWORK_NAME}を使えば、すべてが解決される」
原則だけでは不十分
良いアーキテクチャを設計するためには、原則の存在だけでは不十分です。
すべての人が原則を完全に理解しているわけではありません。正しく原則を理解し、適用できる人はさらに少ないです。
設計原則はあまりにも一般的であり、「スケーラブルで柔軟なアプリケーションの構造とアーキテクチャをどのように設計するか？」という具体的な質問に対する答えを提供していません。
プロセスは常に機能するわけではない
ドキュメント/テスト/プロセスを使用するのは、確かに良いことですが、残念ながら、それに多くのコストをかけても、アーキテクチャの問題や新しい人をプロジェクトに導入する問題を解決することは常にできるわけではありません。
- ドキュメントは、しばしば膨大で古くなってしまうので、各開発者のプロジェクトへの参加時間はあまり短縮されない。
- 誰もが同じようにアーキテクチャを理解しているかを常に監視することは、膨大なリソースを必要とする。
- bus-factorも忘れないようにしましょう。
既存のフレームワークはどこでも適用できるわけではない
- 既存の解決策は通常、高い参入障壁があるため、新しい開発者を見つけるのが難しい。
- ほとんどの場合、技術の選択はプロジェクトの深刻な問題が発生する前に決定されているため、技術に依存せずに、すでにあるもので作業をすることができなければならない。
Q: 「私のプロジェクトでは
React/Vue/Redux/Effector/Mobx/{YOUR_TECH}を使っていますが、エンティティの構造とそれらの間の関係をどのように構築すればよいでしょうか？」
結果として
「雪の結晶」のようにユニークなプロジェクトが得られ、それぞれが従業員の長期的な関与を必要とし、他のプロジェクトではほとんど適用できない知識を必要とします。
@sergeysova: これは、現在のフロントエンド開発の状況そのものであり、各リーダーがさまざまなアーキテクチャやプロジェクトの構造を考案しているが、これらの構造が時間の試練に耐えるかどうかは不明であり、最終的にはリーダー以外の人がプロジェクトを発展させることができるのは最大で2人であり、新しい開発者を再び入れる必要がある。
開発者にとっての方法論の必要性
アーキテクチャの問題ではなくビジネス機能に集中するため
FSDは、スケーラブルで柔軟なアーキテクチャの設計にかかるリソースを節約し、開発者の注意を主要な機能開発に向けることを可能にしています。 同時に、プロジェクトごとにアーキテクチャの解決策も標準化されます。
別の問題は、FSDがコミュニティの信頼を得る必要があることです。そうすれば、開発者は自分のプロジェクトの問題を解決する際に、与えられた時間内にFSDを理解し、信頼することができます。
経験に基づく解決策
FSDは、複雑なビジネスロジックの設計における経験に基づく解決策を目指す開発者を対象としています。
ただし、FSDは、全体としてベストプラクティスのセット、または特定の問題やケースに関する記事一覧です。したがって、開発や設計の問題に直面する他の開発者にも役立てます。
プロジェクトの健康
FSDは、プロジェクトの問題を事前に解決し、追跡することを可能にし、膨大なリソースを必要としません。
技術的負債は通常、時間とともに蓄積され、その解決の責任はリーダーとチームの両方にあります。
FSDは、スケーリングやプロジェクトの発展における潜在的な問題を事前に警告することを可能にしています。
ビジネスにとってのFSD方法論の必要性
迅速なオンボーディング
FSDを使用すると、すでにこのアプローチに慣れている人をプロジェクトに雇うことができ、再教育する必要がありません。
人々はより早くプロジェクトに慣れ、貢献し始め、次のプロジェクトのイテレーションで人を見つけるための追加の保証が得られます。
経験に基づく解決策
ビジネスは、プロジェクトの発展における大部分の問題を解決するフレームワーク/解決策を得たいと考えています。FSDにより、ビジネスはシステムの開発中に発生するほとんどの問題に対する解決策を得ることができます。
プロジェクトのさまざまな段階への適用性
FSDは、プロジェクトのサポートと発展の段階でも、MVPの段階でもプロジェクトに利益をもたらすことができます。
はい、MVPでは通常、機能が重要であり、将来のアーキテクチャは重要ではありません。しかし、限られた時間の中で、方法論のベストプラクティスを 知っていることで、少ないコストで済むことができ、MVPバージョンのシステムを設計する際に合理的な妥協を見つけることができます（無計画に機能を追加するよりも）。
テストについても同じことが言えます。
私たちの方法論が必要ない場合
- プロジェクトが短期間しか存続しない場合
- プロジェクトがサポートされるアーキテクチャを必要としない場合
- ビジネスがコードベースと機能の提供速度の関連性を認識しない場合
- ビジネスができるだけ早く注文を完了することを重視し、さらなるサポートを求めない場合
ビジネスの規模
- 小規模ビジネス - 通常、迅速で即効性のある解決策を必要とします。ビジネスは、成長する（少なくとも中規模に達する）と、顧客が継続的にサービスなどを利用するためには、開発される解決策の品質と安定性に時間をかける必要があることを理解し始めます。
- 中規模ビジネス - 通常、開発のすべての問題を理解しており、たとえ機能をできるだけ早くリリースしたい場合でも、品質の改善、リファクタリング、テスト（そしてもちろん、拡張可能なアーキテクチャ）に時間をかけます。
- 大規模ビジネス - 通常、すで に広範なオーディエンスを持ち、従業員の数も多く、独自のプラクティスのセットを持っているため、他のアプローチを採用するアイデアはあまり浮かびません。
目標
主要な目標の大部分はここに記載されていますが、今後のFSD方法論に対する私たちの期待についても話しておく必要があります。
経験の統合
現在、私たちはcore-teamのさまざまな経験を統合し、実践に基づいた方法論を得ることを目指しています。
もちろん、最終的にはAngular 3.0のようなものを得るかもしれませんが、ここで最も重要なのは、複雑なシステムのアーキテクチャ設計の問題を探求することです。
そして、現在のFSD方法論のバージョンに対して不満があることは確かですが、私たちはコミュニティの経験も考慮しながら、共通の努力で統一的かつ最適な解決策に到達したいと考えています。
仕様外の生活
すべてがうまくいけば、FSDは仕様やツールキットに限定されることはありません。
- 講演や記事があるかもしれない。
- FSD 方法論に従って書かれたプロジェクトの他の技術への移行のための
CODE_MODEsがあるかもしれない。 - 最終的には、大規模な技術的解決策のメンテイナーに到達できるかもしれない。
- 特にReactに関しては、他のフレームワークと比較して、これは主な問題である。なぜなら、特定の問題を解決する方法を示さないからである。