SSPS - プロジェクト構造の統一基準

SSPS 標準は、プロジェクト内のファイルおよびフォルダの構造と命名に関する要件を規定しています。

すべて kebab-case

プロジェクト内のすべてのフォルダおよびファイルには、小文字とハイフンを使用することが義務付けられています。これは、一貫性を確保し、問題の発生を防ぐために意図的に選択された表記法です。このアプローチにより、大文字小文字の区別が異なるさまざまなオペレーティングシステムやバージョン管理システム (Git) での競合が防止され、ブランチのマージや CI でのビルド時にエラーが発生することを防ぎます。

kebab-case を使用することで、以下の問題が解決されます。

• つのディレクトリ内に getPrice.ts、Price.tsx、Name.test.ts といった混乱を排除します。
• CuteIDKOKReader のような複雑な名前は、読みやすい cute-id-kok-reader.ts に変換されます。
• 大文字小文字を区別するファイルシステム (Case Sensitive FS) のバグから保護します。

snake_case ではない理由：

• Shift キーの過度な使用が必要。
• ウェブ上での可読性が低い（たとえば、ファイルがアンダースコア付きリンクとして表示された場合、_ は線と混同される）。
• Google はアンダースコアの使用を公式に推奨していない。

インポートのパスは統一された見た目になり、読みやすくなります。唯一の例外は、リポジトリのルートにある README や CONTRIBUTING などのシステムファイルです。これらのファイルの大文字表記は、一般的なドキュメントの標準によって規定されているためです。

ネストによるコンテキスト

ファイル名は、フォルダ構造がすでに提供している情報を重複してはいけない。SSPS では、コンテキストは場所によって決まる。つまり、ファイルが features/auth にあるなら、auth-login-form.tsx という名前は冗長だ。正しいのは login-form.tsx だ。

HeaderUserMenuAvatar のような名前から widgets/header/ui/user-menu/avatar のような構造への移行により、ファイル名を簡潔かつ正確に保つことができます。

FSD のアーキテクチャ原則

プロジェクトは、明確な責任範囲を持つ層構造で構築されています。グローバルグループ（entities、features、widgets）は常に複数形で命名されます。それらの内部にある具体的なモジュール（スライス）は単数形で命名されます。内部セグメント（ui、model、api）は標準のままです。

これにより予測可能なアーキテクチャが構築され、カートを変更するタスクは常に features/add-to-cart に導かれ、インターフェースとロジックが明確に分離されます。統一された大文字小文字の規則（kebab-case）を使用することでプロジェクトが均一化され、迅速な方向性の決定とタスクの解決が可能になります。