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

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

すべて kebab-case

プロジェクト内のすべてのフォルダおよびファイル名には、小文字とハイフンを使用することが必須です。これにより一貫性が保たれ、問題の発生を防ぐことができます。この方法により、大文字と小文字の区別が異なる場合があり、エラーの原因となる可能性のある、さまざまなオペレーティングシステムやバージョン管理システム（Git）間での競合を回避できます。

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

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

snake_case ではない理由：

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

唯一許容される例外は、リポジトリのルートにあるREADMEやCONTRIBUTINGといったシステムファイルです。これらは、ドキュメント作成の一般的な標準に従って大文字で表記されるためです。

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

ファイル名は、フォルダ構造がすでに提供している情報を重複して含んではなりません。コンテキストは場所によって決まります。つまり、ファイルが 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）を使用することでプロジェクトが均一化され、迅速な方向性の決定とタスクの解決が可能になります。

記事は随時更新されます