コードレビュー診断

体系的なコードレビューは本番環境への欠陥流出を60～90%削減し、保守コストを40%削減し、効果的な知識移転として機能します。このスキルは、ヒューマンレビュアーとAIエージェントの両方に対して、構造化されたレビューガイダンスを提供します。

このスキルを使用する場合

以下の場合にこのスキルを使用してください:

• マージ前のコードレビュー
• コード品質の評価
• PR提出前のコード準備
• リクエスト前の自己レビュー

以下の場合は使用しないでください:

• 新しいコードを書く場合(実装スキルを使用)
• アーキテクチャを設計する場合(system-designを使用)
• 要件を扱う場合(requirements-analysisを使用)

中核原則

レビュー効果はPRサイズが大きくなると急激に低下します。 400行以下：欠陥検出が最高。400～800行：50%の効果低下。800行以上：90%の効果低下。

クイックリファレンス：レビュー効果

要素	最適	低下
PRサイズ	< 400行	> 800行
レビュー時間	< 60分	> 90分
レビュー速度	200～400 LOC/時間	> 500 LOC/時間
レビュアー数	2人	4人以上(収穫逓減)

品質ピラミッド

レベル	チェック項目	検出率	頻度
1. 自動化	Lint、型チェック、ユニットテスト、セキュリティスキャン	60%	全コミット
2. 統合テスト	統合テスト、契約テスト、パフォーマンステスト	25%	全PR
3. ヒューマンレビュー	設計、ロジック、保守性、コンテキスト	15%	重要な変更

レビュー焦点領域

1. 正確性

チェック項目:

• 記述されている問題を解決しているか?
• エッジケースは処理されているか?
• エラーハンドリングは完全か?
• 仮定は妥当か?

検証方法: テストカバレッジ、ビジネスロジック、データ整合性、並行処理

2. 保守性

チェック項目:

• コードは自己説明的か?
• 簡単に修正できるか?
• 抽象化は適切か?
• 複雑性は正当化されているか?

指標: 明確な命名、単一責任、最小限の結合、高い凝集度

3. パフォーマンス

チェック項目:

• 明らかなボトルネックはあるか?
• キャッシュは適切か?
• クエリは最適化されているか?
• メモリは適切に管理されているか?

危険信号: N+1クエリ、無限ループ、非同期コンテキストでの同期I/O、メモリリーク

4. セキュリティ

チェック項目:

• 入力は検証されているか?
• シークレットは保護されているか?
• 認証はチェックされているか?
• パーミッションは検証されているか?

重要チェック: ハードコードされたシークレットがない、SQLはパラメータ化、XSS対策、CSRFトークン

コードスメルチェックリスト

メソッドレベル

スメル	閾値	対応
長いメソッド	> 50行	メソッド抽出
長いパラメータリスト	> 5パラメータ	パラメータオブジェクト
重複コード	> 10行の類似	共通部分を抽出
デッドコード	呼び出されない	削除

クラスレベル

スメル	症状	対応
神クラス	> 1000行、> 20メソッド	クラス分割
機能の嫉妬	他のクラスのデータを過度に使用	メソッド移動
データ凝集	同じパラメータグループ	クラス抽出

アーキテクチャレベル

スメル	検出方法	対応
循環依存	依存関係のサイクル	インターフェース導入
不安定な依存	不安定なモジュールへの依存	依存性の反転

コメントガイドライン

コメントタイプ

[BLOCKING] - マージ前に修正必須

• セキュリティ脆弱性、データ破損リスク、API破壊的変更

[MAJOR] - マージ前に修正推奨

• テスト不足、パフォーマンス問題、コード重複

[MINOR] - フォローアップで修正可

• スタイル不一致、ドキュメント誤字、命名改善

[QUESTION] - 明確化を求める

• 設計決定、ビジネスロジック、外部依存

効果的なコメントパターン

観察 + 影響 + 提案

例:
"このメソッドは200行です[観察]。
これは理解とテストを難しくします[影響]。
ヘルパーメソッドの抽出を検討してください[提案]。"

避けるべき表現

• 曖昧: 「これは改善できます」
• 個人的: 「これは好きではありません」
• 細かすぎる: 「コメントにピリオドがない」
• 圧倒的: 50以上のスタイル指摘

レビュー準備チェックリスト

レビューリクエスト前

• 機能は完全に実装されている
• すべてのテストが書かれており合格している
• 自己レビューを実施している
• コメントアウトされたコードやデバッグ文がない
• カバレッジ閾値を満たしている
• Lint エラーがない
• ビルドが成功している
• ドキュメントが更新されている
• PR説明で問題と解決策を説明している

PR説明に含むべき内容

• 問題ステートメント(なぜこの変更が必要か?)
• 解決アプローチ(どのように解決するか?)
• テスト戦略(どう検証したか?)
• 破壊的変更(あれば)
• レビュー焦点領域(どこを詳しく見るか?)

複雑性の閾値

サイクロマティック複雑度

範囲	分類	対応
1～10	シンプル	OK
11～20	中程度	リファクタリング検討
21～50	複雑	リファクタリング必須
> 50	テスト不可能	分解必須

認知複雑度

範囲	分類
< 7	明確
7～15	許容可能
> 15	混乱している - リファクタリング必要

アンチパターン

ゴム印判子

十分なレビューなしに承認。1分未満で「LGTM」。 修正方法: 最小レビュー時間、必須コメント、ランダム監査。

細かすぎる指摘

50以上のスタイルコメント、本当の問題を見落とす。 修正方法: スタイルチェックを自動化、ロジック/設計に焦点、軽微なコメントを制限。

ビッグバンレビュー

2000行以上のPRで圧倒。 修正方法: 小さなPRを積み重ねる、機能フラグ、ドラフトレビューを早期に。

セキュリティスキャンカテゴリ

重要度分類

レベル	定義	SLA
Critical	リモートコード実行の可能性	即座に修正
High	データ流出の可能性	24時間以内に修正
Medium	限定的な影響	スプリント内に修正
Low	最小限のリスク	都合がつき次第修正

レビューメトリクス

効率性

メトリクス	目標
初回レビュー対応時間	< 4時間
レビュー反復回数	< 3回
PRからマージまで	< 24時間

品質

メトリクス	目標
欠陥検出率	> 80%
マージ後の欠陥	PR当たり < 0.5件
レビューカバレッジ	100%

関連スキル

• github-agile - PRワークフローとGitHub統合
• task-decomposition - PRが大きすぎる場合は分割
• requirements-analysis - 要件が不明確な場合