featuresディレクトリに学ぶディレクトリ構成の考え方
React界では数年前にfeaturesディレクトリというディレクトリ構成が登場しました。
featuresディレクトリとは一つのディレクトリ構成のパターンです。機能単位(feature)でコードを整理する方法で、featuresというディレクトリを作成します。
以下のような構成となります。
日本ではこちらの記事がその火付け役だったんじゃないでしょうか。
他にもfeaturesディレクトリについてたくさんの記事が書かれ、多くのプロジェクトで採用されていると思います。私も採用しています。つまり一時的な流行ではなくエンジニアに受け入れられたアイディアだと思っています。
この記事では、なぜfeaturesディレクトリがなぜエンジニアに受け入れられたのかを考察し、フロントエンドだけではく一般化したディレクトリ構成を考え方を検討してみたいと思います。
ディレクトリ構成 = コードの属性とその優先順位
featuresディレクトリが登場する以前のReactプロジェクトでは、次のようなディレクトリ構成が多かったと思います。
このディレクトリ構成は、コードを言語やライブラリーから見た技術という視点で分類したものでした。
一方、featuresディレクトリでは、コードがどの機能に関わっているのかという視点で最初に分類します。
featuresディレクトリの登場により、コードがもつ色々な属性のうちどの属性に着目するのかという視点の数だけディレクトリの切り方が考えられるということを私は学びました。そして、ディレクトリはネストした構造を持つことができるので、着目するコードの属性の数とその優先順位によって、ディレクトリ構成のルールが考えられます。
| ルール | パス |
|---|---|
| 技術に着目 | src/技術名/様々な機能のコードのファイル |
| 機能に着目 | src/機能名/様々な技術のファイル |
| 機能、技術の順に着目する | src/features/機能名/技術名/機能、技術で整理されたファイル |
featuresディレクトリがなぜエンジニアに受け入れられたのか
2つの理由があったと考えています。
- 開発作業は機能単位で管理されているケースが多い
- パスが適切に分散するのでファイルが探しやすい
開発作業は機能単位で管理されているケースが多い
featuresディレクトリにはさまざまなメリットがありますが、機能単位で考えることが開発チームにとって自然だったからfeaturesディレクトリが広まったのではないかと私は考えています。
アプリケーション開発では特定の技術に着目したPRより、機能やバグに着目したPRの方が多くが作られます。そのため作業、PR、レビューにおいて、featuresディレクトリによる構成は自然だと感じられます。
もしも将来、機能と技術以外のコードの属性としてAという属性に着目してディレクトリ構成を検討するとします。開発作業で考慮する優先順位が「機能 > A > 技術」である場合、ディレクトリ構成はfeatures/機能名/A/技術名とすることでより開発しやすいディレクトリ構成に発展するかもしれません。
パスが適切に分散するのでファイルが探しやすい
featuresディレクトリが登場する以前のディレクトリ構成の問題として、例えばcomponentsディレクトリ以下が完全にフラットだと、ファイルの命名ルールを追加しない限りは目的のファイルを探すことが非常に困難となります。
featuresディレクトリでは、機能名、技術名というディレクトリが切られることでパスが分散します。その粒度がちょうどよいと感じます。私の関わっているプロジェクトである機能名、ある技術名のディレクトリを開いたときに10を超えるファイルが格納されている、というケースはほとんどありません。それだけファイルを把握し易くなりました。
再び機能と技術以外のコードの属性としてAという属性に着目してディレクトリ構成を検討するとして、開発作業で考慮する優先順位が「機能 > A = 技術」である場合は、技術とAでどちらがより分散するか、という視点でディレクトリ構成を決めても良いかもしれません。
まとめ
開発チームにとって重要な関心ごとが「機能」であったためfeaturesディレクトリが広まったのだと思います。
featuresディレクトリで更なる不満を感じる場面があった際には、何に関心を向けているのか、向けたいのか考えましょう。
不満の先にある概念に気がつくことができれば、それがディレクトリ構成のさらなるブラッシュアップのチャンスかもしれません。
Discussion