Web フロントエンドにおけるコロケーション (co-location) という考え方について

Webフロントエンド界隈の文献などにあたっていると、「コロケーション (co-location)」という考え方が時々登場します。

コロケーションを簡単に説明すると、関連するリソース同士を近くに置いておく、という考え方です。

FooComponent.tsx と同じディレクトリに FooComponent.test.tsx を置く
GraphQL fragment は、クエリを発行するコンポーネントファイル (pages/user.tsx) ではなく、fragment を利用するコンポーネントファイル (components/UserInfo.tsx) の中で定義する
- pages/user.tsx からはサブコンポーネントのファイルで定義されている fragment を import してきて、クエリを組み立てて発行する
API ドキュメントは API.md に書くのではなく、コードの中にドキュメンテーションコメントとして書く
- API ドキュメントはドキュメンテーションコメントから自動生成する

関連するもの同士を近くに置いておくことで、以下のようなメリットが得られます。

テストファイルの場合
- src/in/deep/directory/FooComponent.tsx と test/in/deep/directory/FooComponent.tsx を行ったり来たりする手間から開放されます
- テストファイルが目につきやすくなります
  - 「テストコードを書く参考にするために、他のテストファイルの書き方を見に行く」といったことがやりやすくなります
  - 実装に対応するテストがないことが、src/in/deep/directory を見るだけでわかります
GraphQL fragment の場合
- コンポーネントで新たな GraphQL field が必要になったら、そのファイル内にある fragment の定義を編集するだけで、field を取得できます
- pages/user.tsx と components/UserInfo.tsx を行ったり来たりする手間から開放されます
API ドキュメントの場合
- API ドキュメントが API.md に書かれていると、実装を進めている間に存在を忘れてしまい、実装とドキュメントが乖離しがちです
- 実装とドキュメントをそばに置いておけば、乖離が発生しにくくなります

色々な記事でこの考え方が紹介・参照されています。

コロケーションは保守性や可読性を向上させるため、長期的に見れば良いメリットが多く得られます。また考え方を知っておけば、「このファイルをどこに置くか」などといった開発中の悩みも軽減されるため、開発速度の向上にも繋がります。

フロントエンド界隈で注目されている考えではありますが、その他の界隈でも適用できる普遍的な考え方だと思います。

コロケーションのさじ加減

とはいえコロケーションもノーコストでできる訳ではありません。本来ページコンポーネントにベタ書きで良かったものを GraphQL fragment に切り出して持ってきたり、ドキュメンテーションコメントからドキュメントファイルを生成するツールを導入したりと、ちょっとした手間が発生します。コロケーションにすることで長期的に得られるメリットと比較すれば大したコストではないですが、短期的に見ると無視できないコストです。書きなぐるようにサクサクコーディングしたい、というケースではかえってわずらわしく感じるかもしれません。

コロケーションはあくまでリソースの配置方法に関する1つの考え方であり、プロジェクトや状況によって適切な解決策を取り入れていくのが望ましいと思います。