223 lines
5.4 KiB
Markdown
223 lines
5.4 KiB
Markdown
---
|
||
description: 機能を実装する
|
||
argument-hint: [追加の指示（オプション）]
|
||
---
|
||
|
||
# 機能の実装
|
||
|
||
機能仕様書とテストケースに基づいて、機能を実装します。
|
||
TDDのRed-Green-Refactorサイクルに従って進めます。
|
||
|
||
## 追加の指示
|
||
$ARGUMENTS
|
||
|
||
## 実装の指針
|
||
|
||
`implementer` エージェントを使って、テストを通すための実装を進めてください。
|
||
|
||
## タスク状態の更新
|
||
|
||
実装を開始する前に、タスク状態を更新してください：
|
||
|
||
```javascript
|
||
// .tasks.json の該当タスクを更新
|
||
{
|
||
"id": 5,
|
||
"type": "workflow",
|
||
"name": "実装",
|
||
"status": "in_progress",
|
||
"command": "/implement",
|
||
"startedAt": "[現在時刻]"
|
||
}
|
||
```
|
||
|
||
実装フェーズでは、サブタスクを作成している場合、各サブタスクの状態も適宜更新してください：
|
||
- `/update-task [タスクID] in_progress` - タスク開始時
|
||
- `/complete-task [タスクID]` - タスク完了時
|
||
|
||
## Red-Green-Refactor サイクル
|
||
|
||
### フェーズ1: Red（失敗するテストの確認）
|
||
|
||
まず、作成したテストを実行して失敗を確認します：
|
||
|
||
```bash
|
||
# テストを実行
|
||
npm test # または pytest, go test, など
|
||
```
|
||
|
||
失敗メッセージから、何を実装すべきかを理解します。
|
||
|
||
### フェーズ2: Green（最小限の実装）
|
||
|
||
**目標**: テストを通すこと（美しいコードは後回し）
|
||
|
||
#### 実装の優先順位
|
||
|
||
1. **コアロジックから**
|
||
- 最も重要な機能
|
||
- 他の機能が依存する部分
|
||
|
||
2. **正常系を先に**
|
||
- 一般的なユースケース
|
||
- ハッピーパス
|
||
|
||
3. **エラーハンドリング**
|
||
- 異常系の処理
|
||
- 例外処理
|
||
|
||
4. **エッジケースの対応**
|
||
- 境界値の処理
|
||
- 特殊なケース
|
||
|
||
#### 実装のステップ
|
||
|
||
```
|
||
1. 1つのテストケースに注目
|
||
2. そのテストを通す最小限のコードを書く
|
||
3. テストを実行
|
||
4. 通ったら次のテストへ
|
||
5. 失敗したらデバッグして修正
|
||
6. すべてのテストが通るまで繰り返し
|
||
```
|
||
|
||
### フェーズ3: Refactor（リファクタリング）
|
||
|
||
すべてのテストが通ったら、コードを改善します：
|
||
|
||
#### リファクタリング観点
|
||
|
||
1. **重複の削除**
|
||
- DRY原則に従う
|
||
- 共通処理を関数化
|
||
|
||
2. **可読性の向上**
|
||
- わかりやすい変数名
|
||
- 適切なコメント
|
||
- 関数の分割
|
||
|
||
3. **設計の改善**
|
||
- 責任の分離
|
||
- 依存性の注入
|
||
- パターンの適用
|
||
|
||
4. **パフォーマンス最適化**（必要な場合）
|
||
- アルゴリズムの改善
|
||
- キャッシングの追加
|
||
- 不要な処理の削除
|
||
|
||
**重要**: リファクタリング後、必ずテストを実行して機能が壊れていないことを確認
|
||
|
||
## 実装のベストプラクティス
|
||
|
||
### 1. コーディング規約に従う
|
||
|
||
プロジェクトの既存のスタイルを確認：
|
||
- 命名規則
|
||
- インデント（スペースorタブ）
|
||
- ファイル構成
|
||
- コメントの書き方
|
||
|
||
### 2. 小さくコミット
|
||
|
||
```bash
|
||
# 機能単位でコミット
|
||
git add [変更ファイル]
|
||
git commit -m "feat: [機能の説明]"
|
||
|
||
# テストが通る状態でコミット
|
||
# こまめにコミットして履歴を残す
|
||
```
|
||
|
||
### 3. ドキュメントを書く
|
||
|
||
```javascript
|
||
/**
|
||
* ユーザー情報を取得する
|
||
* @param {number} userId - ユーザーID
|
||
* @returns {Promise<User>} ユーザー情報
|
||
* @throws {Error} ユーザーが見つからない場合
|
||
*/
|
||
async function getUser(userId) {
|
||
// ...
|
||
}
|
||
```
|
||
|
||
### 4. エラーハンドリング
|
||
|
||
```javascript
|
||
// 適切なエラーメッセージ
|
||
if (!userId) {
|
||
throw new Error('User ID is required');
|
||
}
|
||
|
||
// エラーのログ記録
|
||
try {
|
||
// ...
|
||
} catch (error) {
|
||
logger.error('Failed to fetch user', { userId, error });
|
||
throw error;
|
||
}
|
||
```
|
||
|
||
### 5. 依存関係の管理
|
||
|
||
新しいライブラリを追加する場合：
|
||
```bash
|
||
# 必要性を検討
|
||
# ライセンスを確認
|
||
# バージョンを固定
|
||
npm install --save-exact package-name
|
||
```
|
||
|
||
## 実装中のチェックリスト
|
||
|
||
- [ ] テストケースを確認した
|
||
- [ ] 最小限の実装から始めた
|
||
- [ ] テストを頻繁に実行している
|
||
- [ ] コーディング規約に従っている
|
||
- [ ] 適切なエラーハンドリングをしている
|
||
- [ ] 必要なコメント・ドキュメントを書いた
|
||
- [ ] リファクタリングをした
|
||
- [ ] すべてのテストが通る
|
||
- [ ] 既存のテストも壊していない
|
||
|
||
## 次のステップ
|
||
|
||
実装が完了したら：
|
||
|
||
1. **すべてのテストを実行**
|
||
```bash
|
||
npm test
|
||
npm run test:coverage # カバレッジも確認
|
||
```
|
||
|
||
2. **コードレビュー依頼**
|
||
- ユーザーにレビューを依頼
|
||
- フィードバックを反映
|
||
|
||
3. **ドキュメント更新**
|
||
- README
|
||
- CHANGELOG
|
||
- APIドキュメント
|
||
|
||
4. **タスクの完了**
|
||
```javascript
|
||
// .tasks.json の該当タスクを更新
|
||
{
|
||
"id": 5,
|
||
"status": "completed",
|
||
"completedAt": "[現在時刻]"
|
||
}
|
||
```
|
||
|
||
5. **完了報告**
|
||
- 実装内容のサマリー
|
||
- テスト結果
|
||
- 今後の課題（あれば）
|
||
|
||
**注意**:
|
||
- `post-implementation` フックが自動的に実行され、実装の品質チェックとテストの実行を行います
|
||
- タスク進捗は `/list-tasks` で確認できます
|
||
- すべてのサブタスクが完了していることを確認してください
|