クリーンコード
目的
不必要な複雑さを導入することなく、コードの可読性、保守性、テスト容易性、一貫性を向上させます。
コア原則
- 意味のある一貫した名前を使用する。
- 関数は単一責任に集中させる。
- 不必要な抽象化よりもシンプルな解決策を優先する。
- ビジネスロジックの重複を避ける。
- 可能な場合はSOLIDの原則に従う。
- 暗黙の結合よりも明示的な依存関係を優先する。
- エラーを明確かつ一貫して処理する。
- コードをテストおよび保守しやすく保つ。
ワークフロー
コードの作成またはリファクタリング時:
- 既存の動作と要件を理解する。
- 具体的なコード品質の問題を特定する。
- 最小限で合理的な改善案を提案する。
- 変更が要求されない限り、既存の機能を維持する。
- プロジェクトの確立されたアーキテクチャと規約に従う。
- 適切な場合は、関連するテストを追加または更新する。
- 重要な変更とトレードオフについて説明する。
リファクタリングガイドライン
- 無関係なモジュールをリファクタリングしない。
- 明確な利点なしにデザインパターンを導入しない。
- 時期尚早な最適化を避ける。
- 継承が不必要な結合をもたらす場合は、コンポジションを優先する。
- 破壊的な変更が明示的に承認されない限り、公開APIの互換性を維持する。
- ビジネスルールを黙って変更しない。
- 正当な理由なく依存関係を追加しない。
検証
タスクを完了する前に:
- 要求された動作が実装されていることを確認する。
- 命名、可読性、重複をレビューする。
- エラーハンドリングとエッジケースを確認する。
- 利用可能な場合は、関連するテストと静的解析を実行する。
- 実行できなかったテストがあれば報告する。
出力の期待値
改善案を提案する場合:
- 特定された問題を説明する。
- 提案された変更を説明する。
- 許可された場合に変更を実装する。
- 関連するトレードオフを説明する。
- 検証結果を要約する。
プロジェクト適応
リポジトリ固有の指示とテクノロジー規約に従う。
リポジトリのコンテキストで確認されない限り、プロジェクトが特定の言語、フレームワーク、データベース、アーキテクチャを使用していると想定しない。