はじめに
本記事に書くのはあくまで私の考えであり、これらの手法を仕事でワークさせたこともないので、一例程度に捉えて欲しい内容になります。
私が実装時に意識していること
個人開発なら正直なんでも好きにすれば良いと思います。最初から売却とか人雇うとか考えてなければ。
ただチーム開発（主にお仕事）の場合は、「新規参画者が入ってくる」を意識することで、他人が修正しやすいコーディングとはなんぞや？といった観点が生まれ、有意義な試行錯誤に発展するのかなと思ってます。
そんな中、私が意識しているのは以下になります。
- 影響範囲がすぐ特定できるか
- grepしやすいか
同じこと言ってますね。そうなんです、私がチーム開発で一番時間かかるなって思ってるのは、影響範囲の特定（および動作確認）になるからです。この辺は人によるから必ずしもそうではないというお断りははじめに同様入れておきます。
具体的にどうやってんの？
私が率先して開発するケースの場合は、例えばNext.jsの場合は以下のようなディレクトリ構成をルール化しています（pages routerの頃）。 これがすべてでは無いですが、言いたいことは伝わると思います。
components（システム全体で使うコンポーネント）
pages
XXXPage
pageComponents（そのページ内でのみ使うコンポーネント。後で共通化されることがあれば、そのタイミングで/componentsに昇華）
hooks（そのページ内でのみ使うhooks）
index.tsx
これをルール化することの何が嬉しいかと言うと、一々grepするまでもなく影響範囲が特定できる点です。
このルールでカバー出来ないものについては、
- 外部にexportする変数や関数名は、一意に特定できる名前にする（＝ grepしやすくする）
- Next.jsのpageとかはexportするもののそもそも別ファイルから読まれない前提なので対象外
- 一方でそのファイルでのみ使うものは、汎用的な名前にする（＝ 似たファイルは一々リネームしなくてもコピペで作りやすくなる。そもそも長い名前は可読性が悪い）
さいごに
駆け足で書いたので本当に要点のみに絞って書きましたが、なんとなくイメージが伝われば幸いです。
その上で、各チーム毎に自分たちの最適解を見つけていけたら楽しそうだなと思います。
