code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Code Review Diagnostic

代码审查诊断

Systematic code review catches 60-90% of defects before production, reduces maintenance costs by 40%, and serves as effective knowledge transfer. This skill provides structured review guidance for both human reviewers and AI agents.

系统化的代码审查可以在生产前发现60%-90%的缺陷，将维护成本降低40%，同时也是有效的知识传递方式。本技能为人工审查者和AI Agent提供结构化的审查指导。

When to Use This Skill

何时使用本技能

Use this skill when:

Reviewing code before merge
Assessing code quality
Preparing code for PR submission
Self-reviewing before requesting review

Do NOT use this skill when:

Writing new code (use implementation skills)
Designing architecture (use system-design)
Working on requirements (use requirements-analysis)

在以下场景使用本技能：

合并前的代码审查
代码质量评估
为PR提交准备代码
请求他人审查前的自我审查

请勿在以下场景使用本技能：

编写新代码（使用实现类技能）
架构设计（使用系统设计类技能）
需求分析（使用需求分析类技能）

Core Principle

核心原则

Review effectiveness degrades sharply with PR size. Under 400 lines: highest defect detection. 400-800 lines: 50% less effective. 800+ lines: 90% less effective.

审查效果会随着PR规模的增大而急剧下降。 少于400行：缺陷检测率最高。400-800行：效果降低50%。800行以上：效果降低90%。

Quick Reference: Review Effectiveness

快速参考：审查有效性

Factor	Optimal	Degraded
PR size	< 400 lines	> 800 lines
Review time	< 60 minutes	> 90 minutes
Review speed	200-400 LOC/hour	> 500 LOC/hour
Reviewers	2	4+ (diminishing returns)

影响因素	最优标准	效果下降
PR规模	< 400行	> 800行
审查时长	< 60分钟	> 90分钟
审查速度	200-400 LOC/小时	> 500 LOC/小时
审查人数	2人	4人及以上（收益递减）

Quality Pyramid

质量金字塔

Level	Checks	Catches	Frequency
1. Automated	Lint, types, unit tests, security scan	60%	Every commit
2. Integration	Integration tests, contracts, performance	25%	Every PR
3. Human Review	Design, logic, maintainability, context	15%	Significant changes

层级	检查内容	捕捉缺陷占比	执行频率
1. 自动化检查	代码规范检查（Lint）、类型检查、单元测试、安全扫描	60%	每次提交
2. 集成检查	集成测试、契约测试、性能测试	25%	每个PR
3. 人工审查	设计、逻辑、可维护性、上下文合理性	15%	重大变更时

Review Focus Areas

审查重点领域

1. Correctness

1. 正确性

Questions:

Does it solve the stated problem?
Are edge cases handled?
Is error handling complete?
Are assumptions valid?

Validation: Test coverage, business logic, data integrity, concurrency handling

问题：

是否解决了既定问题？
是否处理了边缘情况？
错误处理是否完整？
假设条件是否有效？

验证方式： 测试覆盖率、业务逻辑、数据完整性、并发处理

2. Maintainability

2. 可维护性

Questions:

Is the code self-documenting?
Can it be easily modified?
Are abstractions appropriate?
Is complexity justified?

Indicators: Clear naming, single responsibility, minimal coupling, high cohesion

问题：

代码是否具备自文档性？
是否易于修改？
抽象是否恰当？
复杂度是否合理？

判断指标： 清晰的命名、单一职责、低耦合、高内聚

3. Performance

3. 性能

Questions:

Are there obvious bottlenecks?
Is caching appropriate?
Are queries optimized?
Is memory managed?

Red Flags: N+1 queries, unbounded loops, synchronous I/O in async context, memory leaks

问题：

是否存在明显的性能瓶颈？
缓存使用是否恰当？
查询是否经过优化？
内存管理是否合理？

危险信号： N+1查询、无边界循环、异步上下文同步I/O、内存泄漏

4. Security

4. 安全性

Questions:

Is input validated?
Are secrets protected?
Is authentication checked?
Are permissions verified?

Critical Checks: No hardcoded secrets, SQL parameterized, XSS prevention, CSRF tokens

问题：

输入是否经过验证？
敏感信息是否得到保护？
身份验证是否已检查？
权限是否已验证？

关键检查项： 无硬编码敏感信息、SQL参数化、XSS防护、CSRF令牌

Code Smells Checklist

代码坏味道检查表

Method Level

方法层面

Smell	Threshold	Action
Long method	> 50 lines	Extract method
Long parameter list	> 5 params	Parameter object
Duplicate code	> 10 similar lines	Extract common
Dead code	Never called	Remove

坏味道	阈值	处理建议
过长方法	> 50行	提取方法
过长参数列表	> 5个参数	使用参数对象
重复代码	> 10行相似代码	提取公共部分
死代码	从未被调用	删除

Class Level

类层面

Smell	Symptoms	Action
God class	> 1000 lines, > 20 methods	Split class
Feature envy	Uses other class data excessively	Move method
Data clumps	Same parameter groups	Extract class

坏味道	症状	处理建议
上帝类	> 1000行、>20个方法	拆分类
特性依恋	过度使用其他类的数据	移动方法
数据泥团	重复出现的参数组	提取类

Architecture Level

架构层面

Smell	Detection	Action
Circular dependencies	Dependency cycles	Introduce interface
Unstable dependencies	Depends on volatile modules	Dependency inversion

坏味道	检测方式	处理建议
循环依赖	存在依赖循环	引入接口
不稳定依赖	依赖易变模块	依赖倒置

Comment Guidelines

评论指南

Comment Types

评论类型

[BLOCKING] - Must fix before merge

Security vulnerabilities, data corruption risks, breaking API changes

[MAJOR] - Should fix before merge

Missing tests, performance issues, code duplication

[MINOR] - Can fix in follow-up

Style inconsistencies, documentation typos, naming improvements

[QUESTION] - Seeking clarification

Design decisions, business logic, external dependencies

[BLOCKING] - 合并前必须修复

安全漏洞、数据损坏风险、破坏性API变更

[MAJOR] - 合并前应修复

缺失测试、性能问题、代码重复

[MINOR] - 可在后续修复

风格不一致、文档拼写错误、命名优化

[QUESTION] - 寻求澄清

设计决策、业务逻辑、外部依赖

Effective Comment Pattern

有效评论模板

Observation + Impact + Suggestion

Example:
"This method is 200 lines long [observation].
This makes it hard to understand and test [impact].
Consider extracting helper methods [suggestion]."

观察结果 + 影响 + 建议

示例：
"该方法长达200行 [观察结果]。
这会导致代码难以理解和测试 [影响]。
建议提取辅助方法 [建议]。"

Avoid

避免

Vague: "This could be better"
Personal: "I don't like this"
Nitpicky: "Missing period in comment"
Overwhelming: 50+ minor style issues

模糊表述："这个可以更好"
个人主观："我不喜欢这个"
吹毛求疵："评论中缺少句号"
过度指责：50+个微小风格问题

Review Readiness Checklist

审查就绪检查表

Before Requesting Review

请求审查前

PR Description Should Include

PR描述应包含

Problem statement (why this change?)
Solution approach (how does it solve it?)
Testing strategy (how verified?)
Breaking changes (if any)
Review focus areas (where to look closely?)

问题陈述（为什么需要此变更？）
解决方案思路（如何解决问题？）
测试策略（如何验证？）
破坏性变更（如有）
审查重点区域（需要重点关注的部分？）

Complexity Thresholds

复杂度阈值

Cyclomatic Complexity

圈复杂度

Range	Classification	Action
1-10	Simple	OK
11-20	Moderate	Consider refactoring
21-50	Complex	Refactor required
> 50	Untestable	Must decompose

范围	分类	处理建议
1-10	简单	无需处理
11-20	中等	考虑重构
21-50	复杂	必须重构
> 50	无法测试	必须拆分

Cognitive Complexity

认知复杂度

Range	Classification
< 7	Clear
7-15	Acceptable
> 15	Confusing - refactor needed

范围	分类
< 7	清晰
7-15	可接受
> 15	易混淆 - 需要重构

Anti-Patterns

反模式

Rubber Stamp

橡皮图章

Approving without thorough review. "LGTM" in < 1 minute. Fix: Minimum review time, required comments, random audits.

未进行彻底审查就批准。1分钟内回复“LGTM”。 解决方法： 设定最短审查时长，要求必须添加评论，随机审计。

Nitpicking

吹毛求疵

50+ style comments, missing real issues. Fix: Automate style checks, focus on logic/design, limit minor comments.

提出50+个风格类评论，忽略真正的问题。 解决方法： 自动化风格检查，聚焦逻辑/设计，限制微小问题评论数量。

Big Bang Review

大爆炸式审查

2000+ line PRs that overwhelm. Fix: Stack small PRs, feature flags, review drafts early.

2000+行的PR，让人无从下手。 解决方法： 拆分为小型PR，使用功能标志，提前审查草稿。

Security Scanning Categories

安全扫描分类

Severity Classification

严重程度分类

Level	Definition	SLA
Critical	Remote code execution possible	Fix immediately
High	Data breach possible	Fix within 24 hours
Medium	Limited impact	Fix within sprint
Low	Minimal risk	Fix when convenient

级别	定义	处理时效
关键	可能存在远程代码执行风险	立即修复
高	可能存在数据泄露风险	24小时内修复
中	影响有限	迭代周期内修复
低	风险极小	方便时修复

Review Metrics

审查指标

Efficiency

效率

Metric	Target
First review turnaround	< 4 hours
Review cycles	< 3
PR to merge time	< 24 hours

指标	目标值
首次审查响应时间	< 4小时
审查轮次	< 3次
PR到合并时长	< 24小时

Quality

质量

Metric	Target
Defect detection rate	> 80%
Post-merge defects	< 0.5 per PR
Review coverage	100%

指标	目标值
缺陷检测率	> 80%
合并后缺陷数	< 0.5个/PR
审查覆盖率	100%

code-review

Original

Translation

Code Review Diagnostic

代码审查诊断

When to Use This Skill

何时使用本技能

Core Principle

核心原则

Quick Reference: Review Effectiveness

快速参考：审查有效性

Quality Pyramid

质量金字塔

Review Focus Areas

审查重点领域

1. Correctness

1. 正确性

2. Maintainability

2. 可维护性

3. Performance

3. 性能

4. Security

4. 安全性

Code Smells Checklist

代码坏味道检查表

Method Level

方法层面

Class Level

类层面

Architecture Level

架构层面

Comment Guidelines

评论指南

Comment Types

评论类型

Effective Comment Pattern

有效评论模板

Avoid

避免

Review Readiness Checklist

审查就绪检查表

Before Requesting Review

请求审查前

PR Description Should Include

PR描述应包含

Complexity Thresholds

复杂度阈值

Cyclomatic Complexity

圈复杂度

Cognitive Complexity

认知复杂度

Anti-Patterns

反模式

Rubber Stamp

橡皮图章

Nitpicking

吹毛求疵

Big Bang Review

大爆炸式审查

Security Scanning Categories

安全扫描分类

Severity Classification

严重程度分类

Review Metrics

审查指标

Efficiency

效率

Quality

质量

Related Skills

相关技能