メンテナンスが容易

フォルダー構造は将来の開発者が最初に判断することを保証します。意見が明確で一貫したフォルダー構造が使用されています（例：src/components、src/services、src/hooks、src/features）。

私たちはコンパイラのためだけではなく、人間のためにコードを書きます。一貫した命名規則とパターンがすべてのプロジェクトで守られています。ESLintとPrettierは、Huskyのようなプリコミットフックを介してフォーマットを強制するように設定されており、最初からコードの品質を確保します。私たちは型付き言語を優先し、メンテナンス性を向上させるためにJavaScriptの代わりにTypeScriptを使用します。常にコードを読みやすく、管理しやすく、集中し、小さく保ちます。

再利用可能なコードコンポーネントにデザインの決定をエンコードすることで、デザインの混乱を避けます。ShadCN、Tailwind UI、またはMaterial UIのような確立されたコンポーネントシステムを使用して、プロジェクト間の一貫性を確保します。このアプローチは、絶対に必要な場合を除いて、ワンオフのUIコードを書くことを避け、時間を節約し、デザインの一貫性を確保します。

ビジネスロジックはUI層に存在しないことを保証します。サービス層、カスタムフック、またはコントローラーモジュールを使用して、ビジネスロジックを適切に分離し、整理します。APIとのやり取りには、SWR、React Query、またはキャッシュとエラーステートを効率的に処理するカスタムラッパーを使用した最新のデータフェッチパターンが実装されています。すべてのAPI呼び出しは、services/api/user.tsのような専用のサービスフォルダーに抽象化されており、コードベースはよりメンテナブルでテスト可能になります。

小説は書きません—次の開発者を迅速にオンボードするために十分な情報を提供します。README.mdは常にセットアップ、環境変数、デプロイメント手順を含めて書かれます。複雑なロジックには短いコメントが追加されます（過剰なコメントは避けます）。公開メソッドにはTSDoc / JSDocが使用されます。テストの実行方法や規約についてはCONTRIBUTING.mdが追加されます。

100%のカバレッジは必要ありませんが、失敗が高コストな場所では完全なカバレッジが必要です。ユニットテストはビジネスクリティカルな機能を優先します。統合テストはAPIエンドポイントやワークフローに使用されます。使いやすいツールが選ばれます: Jest + Testing Library (React)、e2eにはPlaywrightを使用します。これにより、カバレッジと市場投入までの時間のバランスを保つことができます。

すべてのコミットは安全チェックをトリガーします。タイプチェック（例: tsc --noEmit）、Lint/フォーマットチェック、ユニットテスト、ステージングへの自動デプロイを行うシンプルなCI/CDパイプラインが設定されています。一般的なツールが使用されます: GitHub Actions、Docker Compose。

ハードコーディングは避けます = 長期的な痛み。すべての秘密/設定は.envまたはリモート設定（例: AWS SSM、Vercel envs）に保存されます。環境ベースのセットアップが使用されます（process.env.NODE_ENV）。.env.*、APIキー、認証情報などのコミットは避けられます。そして、それらは十分に文書化されています。