可审阅补丁与代码评审闭环

明确补丁范围与调用契约

需能阅读 Python 的列表、条件和除法。空列表评审案例同时提供原实现、候选修复和输入表：先追踪 average([])，再检查 [0] 是否仍返回 0.0，最后把触发条件、修改与复核写成意见。无需评审平台账号。 示例未在本轮执行。

代码审查 范围

代码审查范围应是一项可说明的行为变化。描述给出触发条件、变化前后和验收证据；把格式整理与功能混在一起会增加阅读成本，先让补丁能对应需求。

代码审查 上下文

代码审查上下文包括调用方、被调用方和兼容约定。只看新增行可能漏掉所有权和错误传播；沿实际入口追踪结果怎样被使用，说明哪些假设来自代码，哪些尚待确认。

代码审查 优先级

代码审查优先级由影响和触发概率决定。会导致数据丢失或核心流程失败的问题应明确阻断；命名偏好与可选简化标为建议，避免把个人风格当成正确性缺陷。

依据与适用范围

• 本课官方依据，资料核对日2026-10-17。

以上依据用于解释本文列明的规则；示例未执行，不代表产品全部能力或跨平台验证。历史资料的版本、账号与界面位置需按目标环境确认。

用输入和结果支撑评审意见

代码审查 问题证据

代码审查问题证据应给出具体输入、相关代码和错误结果。无法说明触发条件的猜测先调查，不写成确定缺陷；建议改法是辅助，重点是原实现为何违背契约。

代码审查 测试有效性

代码审查测试有效性看是否验证需求而非照抄实现。边界和失败用例应能在错误版本失败；测试通过只证明覆盖到的场景，不代替兼容性和资源释放路径审阅。

代码审查 协作分工

代码审查协作分工需要明确作者、审阅者和决策者。重复意见合并为同一问题，修改后由原问题的证据复核；关联任务记录验收条件，不能用看板状态代替真实完成。

复核误报、查询与过期补丁

代码审查 误报

代码审查误报常来自忽略前置校验或调用契约。提出缺陷前先看非法输入是否能到达该函数；如果保证只在文档中存在，注明契约依赖，不凭空扩大支持范围。

协作 JQL 空值

协作中的JQL空值查询需显式包含EMPTY：assignee != currentUser()不会自动包含无人负责项。筛选条件与ORDER BY排序要分开，状态名和自定义字段需核对项目，历史示例不代表现行看板配置。

代码审查 过期补丁

代码审查过期补丁是审阅基线已变化的结果。后续提交改变相关逻辑后应重看依赖与测试，不能把旧版本批准当作新版本全部正确；最终描述应围绕实际交付范围重写。