【要約】src/config でゼロハードコーディング — 「業務的意味を持つ値」を集約する設計パターン [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が定数を複数の箇所にハードコードすることで、仕様変更時に修正漏れが発生する問題に直面する。その結果、UIとAPIのバリデーションが食い違うなどの不整合が生じる。具体的には以下の課題がある。
- ・整合性の欠如：UIの入力制限とサーバー側のバリデーションが乖離する。
- ・意図の不明瞭さ：bcryptのコスト等の値の根拠が不明で、再検討が必要になる。
- ・ビルドエラー：Next.jsでService層の定数をClient Componentから参照すると、Prisma等の依存関係が混入しビルドが失敗する。
// Approach
設計者は、業務的な意味を持つ定数を src/config/ に集約し、技術的な定数と分離する手法を採用する。これにより、変更時の影響範囲を最小化する。具体的な手法は以下の通りである。
- ・定数の分類：ユーザーに影響する「業務的定数」を src/config/ へ、技術的な「技術的定数」を src/lib/ へ配置する。
- ・ドキュメント化：JSDocを用いて、値の選定根拠や変更時の注意点を明文化する。
- ・依存関係の隔離：src/config/ 内ではPrismaやAuthなどの外部モジュールを一切importせず、純粋な定数モジュールとして保つ。
// Result
運用中のSaaSにおいて、仕様変更時の影響範囲を特定するためのgrep作業が、常に1箇所で完結する状態を実現した。これにより、開発者は以下の恩恵を受ける。
- ・保守性の向上：定数の変更に伴う修正漏れのリスクを構造的に排除した。
- ・開発効率の改善：JSDocにより、値の選定理由を即座に把握可能にした。
- ・ビルドの安定化：依存関係の分離により、Next.js App Routerでのビルドエラーを回避した。
Senior Engineer Insight
> 本手法は、単なる整理術ではなく、依存関係の制御（Dependency Management）という観点で極めて実戦的である。特にNext.jsのClient/Server境界におけるビルドエラーへの対策は、現場でのトラブル回避に直結する。ただし、定数の「業務的意味」の境界線については、チーム内での厳格な定義が必要だ。これを怠ると、src/config/ が肥大化し、設計の意図が形骸化する恐れがある。