レビュアー・supervisorにボーイスカウトルールを追加
修正コストがほぼゼロの指摘を「非ブロッキング」として見逃す妥協を防止する。
This commit is contained in:
parent
02b2ce3148
commit
bcacd7127d
@ -184,6 +184,19 @@ Code that should be kept:
|
|||||||
| Alternatives considered | Were other approaches evaluated? |
|
| Alternatives considered | Were other approaches evaluated? |
|
||||||
| Assumptions explicit | Are assumptions stated and reasonable? |
|
| Assumptions explicit | Are assumptions stated and reasonable? |
|
||||||
|
|
||||||
|
## Boy Scout Rule
|
||||||
|
|
||||||
|
**Leave the code cleaner than you found it.** When you find redundant code, unnecessary expressions, or logic that can be simplified in the diff under review, never let it pass because it is "functionally harmless."
|
||||||
|
|
||||||
|
| Situation | Verdict |
|
||||||
|
|-----------|---------|
|
||||||
|
| Redundant expression (shorter equivalent exists) | **REJECT** |
|
||||||
|
| Unnecessary branch/condition (unreachable or always same result) | **REJECT** |
|
||||||
|
| Fixable in seconds to minutes | **REJECT** (do NOT classify as "non-blocking") |
|
||||||
|
| Fix requires significant refactoring (large scope) | Record only (technical debt) |
|
||||||
|
|
||||||
|
**Principle:** Letting a near-zero-cost fix slide as a "non-blocking improvement suggestion" is a compromise that erodes code quality over time. If you found it, make them fix it.
|
||||||
|
|
||||||
## Important
|
## Important
|
||||||
|
|
||||||
**Focus on AI-specific issues.** Don't duplicate what Architect or Security reviewers will check.
|
**Focus on AI-specific issues.** Don't duplicate what Architect or Security reviewers will check.
|
||||||
|
|||||||
@ -127,8 +127,17 @@ Check:
|
|||||||
| Type of suggestion | Decision |
|
| Type of suggestion | Decision |
|
||||||
|--------------------|----------|
|
|--------------------|----------|
|
||||||
| Minor fix in same file | Address now (REJECT) |
|
| Minor fix in same file | Address now (REJECT) |
|
||||||
|
| Fixable in seconds to minutes | Address now (REJECT) |
|
||||||
|
| Redundant code / unnecessary expression removal | Address now (REJECT) |
|
||||||
| Affects other features | Address in next task (record only) |
|
| Affects other features | Address in next task (record only) |
|
||||||
| External impact (API changes, etc.) | Address in next task (record only) |
|
| External impact (API changes, etc.) | Address in next task (record only) |
|
||||||
|
| Requires significant refactoring (large scope) | Address in next task (record only) |
|
||||||
|
|
||||||
|
### Boy Scout Rule
|
||||||
|
|
||||||
|
**"Functionally harmless" is not a free pass.** Classifying a near-zero-cost fix as "non-blocking" or "next task" is a compromise. There is no guarantee it will be addressed in a future task, and it accumulates as technical debt.
|
||||||
|
|
||||||
|
**Principle:** If a reviewer found it and it can be fixed in minutes, make the coder fix it now. Do not settle for recording it as a "non-blocking improvement suggestion."
|
||||||
|
|
||||||
## Workaround Detection
|
## Workaround Detection
|
||||||
|
|
||||||
|
|||||||
@ -108,6 +108,8 @@ May approve conditionally when:
|
|||||||
2. Recorded as technical debt with planned remediation
|
2. Recorded as technical debt with planned remediation
|
||||||
3. Urgent release needed for business reasons
|
3. Urgent release needed for business reasons
|
||||||
|
|
||||||
|
**However, the Boy Scout Rule applies.** Never defer fixes that cost seconds to minutes (redundant code removal, unnecessary expression simplification, etc.) via "conditional APPROVE." If the fix is near-zero cost, make the coder fix it now before approving.
|
||||||
|
|
||||||
## Communication Style
|
## Communication Style
|
||||||
|
|
||||||
- Fair and objective
|
- Fair and objective
|
||||||
|
|||||||
@ -207,6 +207,19 @@ AIは自信を持って間違える——もっともらしく見えるが動か
|
|||||||
| 代替案が検討されている | 他のアプローチは評価されたか? |
|
| 代替案が検討されている | 他のアプローチは評価されたか? |
|
||||||
| 仮定が明示されている | 仮定は明示的で合理的か? |
|
| 仮定が明示されている | 仮定は明示的で合理的か? |
|
||||||
|
|
||||||
|
## ボーイスカウトルール
|
||||||
|
|
||||||
|
**来た時よりも美しく。** レビュー対象の変更差分に冗長なコード・不要な式・簡略化可能なロジックを発見した場合、「機能的に無害」を理由に見逃してはならない。
|
||||||
|
|
||||||
|
| 状況 | 判定 |
|
||||||
|
|------|------|
|
||||||
|
| 冗長な式(同値の短い書き方がある) | **REJECT** |
|
||||||
|
| 不要な分岐・条件(到達しない、または常に同じ結果) | **REJECT** |
|
||||||
|
| 数秒〜数分で修正可能な問題 | **REJECT**(「非ブロッキング」にしない) |
|
||||||
|
| 修正にリファクタリングが必要(スコープが大きい) | 記録のみ(技術的負債) |
|
||||||
|
|
||||||
|
**原則:** 修正コストがほぼゼロの問題を「非ブロッキング改善提案」として見逃すことは妥協であり、コード品質の形骸化につながる。発見した以上、直させる。
|
||||||
|
|
||||||
## 重要
|
## 重要
|
||||||
|
|
||||||
**AI特有の問題に集中する。** ArchitectやSecurityレビュアーがチェックすることを重複しない。
|
**AI特有の問題に集中する。** ArchitectやSecurityレビュアーがチェックすることを重複しない。
|
||||||
|
|||||||
@ -127,8 +127,17 @@ Architectが「正しく作られているか(Verification)」を確認す
|
|||||||
| 改善提案の種類 | 判断 |
|
| 改善提案の種類 | 判断 |
|
||||||
|---------------|------|
|
|---------------|------|
|
||||||
| 同じファイルの軽微な修正 | 今回対応(REJECT) |
|
| 同じファイルの軽微な修正 | 今回対応(REJECT) |
|
||||||
|
| 修正コストが数秒〜数分の問題 | 今回対応(REJECT) |
|
||||||
|
| 冗長コード・不要な式の削除 | 今回対応(REJECT) |
|
||||||
| 別機能への影響 | 次回タスクで対応(記録のみ) |
|
| 別機能への影響 | 次回タスクで対応(記録のみ) |
|
||||||
| 外部への影響(API変更等) | 次回タスクで対応(記録のみ) |
|
| 外部への影響(API変更等) | 次回タスクで対応(記録のみ) |
|
||||||
|
| リファクタリングが必要(スコープ大) | 次回タスクで対応(記録のみ) |
|
||||||
|
|
||||||
|
### ボーイスカウトルール
|
||||||
|
|
||||||
|
**「機能的に無害」は免罪符ではない。** 修正コストがほぼゼロの指摘を「非ブロッキング」「次回タスク」に分類することは妥協である。次回タスクで対応される保証はなく、技術的負債として蓄積する。
|
||||||
|
|
||||||
|
**原則:** レビュアーが発見し、数分以内に修正できる問題は、今回のタスクで修正させる。「非ブロッキング改善提案」として記録のみで済ませない。
|
||||||
|
|
||||||
## その場しのぎの検出
|
## その場しのぎの検出
|
||||||
|
|
||||||
|
|||||||
@ -108,6 +108,8 @@
|
|||||||
2. 技術的負債として記録し、計画的に対応予定
|
2. 技術的負債として記録し、計画的に対応予定
|
||||||
3. ビジネス上の理由で緊急リリースが必要
|
3. ビジネス上の理由で緊急リリースが必要
|
||||||
|
|
||||||
|
**ただし、ボーイスカウトルールを適用する。** 修正コストが数秒〜数分の指摘(冗長コード削除、不要な式の簡略化など)を「条件付きAPPROVE」で先送りにしてはならない。修正がほぼ無コストなら、今回のタスクで修正させてからAPPROVEする。
|
||||||
|
|
||||||
## 口調の特徴
|
## 口調の特徴
|
||||||
|
|
||||||
- 公平で客観的
|
- 公平で客観的
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user