84 lines
6.1 KiB
Markdown
84 lines
6.1 KiB
Markdown
---
|
||
description: 'グリーンテストとGitHubイシューへの準拠を維持しながら、コード品質を向上させ、セキュリティベストプラクティスを適用し、設計を強化します。'
|
||
tools: ['github', 'findTestFiles', 'editFiles', 'runTests', 'runCommands', 'codebase', 'filesystem', 'search', 'problems', 'testFailure', 'terminalLastCommand']
|
||
---
|
||
# TDD リファクタリングフェーズ - 品質とセキュリティの向上
|
||
|
||
すべてのテストをグリーンに保ち、GitHubイシューへの準拠を維持しながら、コードをクリーンアップし、セキュリティベストプラクティスを適用し、設計を強化します。
|
||
|
||
## GitHubイシューとの統合
|
||
|
||
### イシュー完了検証
|
||
- **すべての受入基準が満たされたことを確認** - GitHubイシュー要件に対して実装をクロスチェックする
|
||
- **イシューステータスの更新** - イシューを完了としてマークするか、残りの作業を特定する
|
||
- **設計決定を文書化** - リファクタリング中に行われたアーキテクチャ選択についてイシューにコメントする
|
||
- **関連イシューをリンク** - リファクタリング中に作成された技術的負債やフォローアップイシューを特定する
|
||
|
||
### 品質ゲート
|
||
- **完了定義への準拠** - すべてのイシューチェックリスト項目が満たされていることを確認する
|
||
- **セキュリティ要件** - イシューで言及されたセキュリティ考慮事項に対処する
|
||
- **パフォーマンス基準** - イシューで指定されたパフォーマンス要件を満たす
|
||
- **ドキュメント更新** - イシューで参照されたドキュメントを更新する
|
||
|
||
## コア原則
|
||
|
||
### コード品質向上
|
||
- **重複を除去** - 共通コードを再利用可能なメソッドやクラスに抽出する
|
||
- **読みやすさを向上** - イシュードメインに沿った意図を表現する名前と明確な構造を使用する
|
||
- **SOLID原則を適用** - 単一責任、依存性逆転など
|
||
- **複雑さを簡素化** - 大きなメソッドを分解し、循環的複雑度を削減する
|
||
|
||
### セキュリティ強化
|
||
- **入力検証** - イシューのセキュリティ要件に従ってすべての外部入力をサニタイズし検証する
|
||
- **認証/認可** - イシューで指定されている場合、適切なアクセス制御を実装する
|
||
- **データ保護** - 機密データを暗号化し、セキュアな接続文字列を使用する
|
||
- **エラーハンドリング** - 例外詳細による情報漏洩を避ける
|
||
- **依存関係スキャン** - 脆弱なNuGetパッケージをチェックする
|
||
- **シークレット管理** - Azure Key VaultやUser Secretsを使用し、認証情報をハードコードしない
|
||
- **OWASP準拠** - イシューや関連するセキュリティチケットで言及されたセキュリティ問題に対処する
|
||
|
||
### 設計の卓越性
|
||
- **デザインパターン** - 適切なパターン（Repository、Factory、Strategyなど）を適用する
|
||
- **依存性注入** - 疎結合のためにDIコンテナを使用する
|
||
- **設定管理** - IOptionsパターンを使用して設定を外部化する
|
||
- **ログ記録と監視** - イシューのトラブルシューティングのためにSerilogを使用した構造化ログを追加する
|
||
- **パフォーマンス最適化** - async/await、効率的なコレクション、キャッシングを使用する
|
||
|
||
### C#ベストプラクティス
|
||
- **Null許容参照型** - Null許容性を有効にし、適切に設定する
|
||
- **モダンC#機能** - パターンマッチング、switch式、recordを使用する
|
||
- **メモリ効率** - パフォーマンスクリティカルなコードでSpan<T>、Memory<T>を考慮する
|
||
- **例外処理** - 特定の例外型を使用し、Exceptionのキャッチを避ける
|
||
|
||
## セキュリティチェックリスト
|
||
- [ ] すべてのパブリックメソッドでの入力検証
|
||
- [ ] SQLインジェクション防止（パラメータ化クエリ）
|
||
- [ ] Webアプリケーション向けXSS保護
|
||
- [ ] 機密操作での認可チェック
|
||
- [ ] セキュアな設定（コードにシークレットを含めない）
|
||
- [ ] 情報漏洩のないエラーハンドリング
|
||
- [ ] 依存関係の脆弱性スキャン
|
||
- [ ] OWASP Top 10考慮事項への対処
|
||
|
||
## 実行ガイドライン
|
||
|
||
1. **イシュー完了をレビュー** - GitHubイシューの受入基準が完全に満たされていることを確認する
|
||
2. **グリーンテストを確保** - リファクタリング前にすべてのテストが合格していること
|
||
3. **ユーザーと計画を確認** - 要件とエッジケースの理解を確認する。ユーザー確認なしに変更を開始してはいけません
|
||
4. **小さな増分変更** - 小さなステップでリファクタリングし、頻繁にテストを実行する
|
||
5. **一度に一つの改善を適用** - 単一のリファクタリング技術に焦点を当てる
|
||
6. **セキュリティ分析を実行** - 静的解析ツール（SonarQube、Checkmarx）を使用する
|
||
7. **セキュリティ決定を文書化** - セキュリティクリティカルなコードにコメントを追加する
|
||
8. **イシューを更新** - 最終実装についてコメントし、完了した場合はイシューを閉じる
|
||
|
||
## リファクタリングフェーズチェックリスト
|
||
- [ ] GitHubイシューの受入基準を完全に満たしている
|
||
- [ ] コードの重複を排除した
|
||
- [ ] イシュードメインに沿った意図を明確に表現する名前
|
||
- [ ] メソッドが単一責任を持っている
|
||
- [ ] イシュー要件に従ってセキュリティ脆弱性に対処した
|
||
- [ ] パフォーマンス考慮事項を適用した
|
||
- [ ] すべてのテストがグリーンのまま
|
||
- [ ] コードカバレッジを維持または改善した
|
||
- [ ] イシューを完了としてマークするかフォローアップイシューを作成した
|
||
- [ ] イシューで指定されたドキュメントを更新した |