2. 代码评审基础
在自动化项目中，代码不仅是“能跑就行”的脚本集合，它往往直接控制设备动作、生产节拍、安全联锁和数据采集。一旦逻辑缺陷进入现场，轻则停机返工，重则造成设备损坏或人身风险。因此，代码评审（Code Review）不是形式化的签字流程，而是把个人经验转化为团队质量屏障的关键活动。
一、代码评审的核心目的
很多团队把评审等同于“找 Bug”，这会导致评审范围过窄。在自动化项目中，评审至少承担五类目的：
- 缺陷预防：在代码合入主干或下载到 PLC 之前，发现逻辑错误、边界遗漏、异常处理缺失等问题。
- 一致性保障：确保命名、状态机结构、报警处理、注释风格符合项目规范，降低后期维护成本。
- 知识共享：让其他成员了解模块设计思路，避免“只有作者能改”的单点依赖。
- 风险控制：识别安全相关逻辑、互锁条件、急停路径是否被正确实现。
- 可追溯性：评审记录可作为质量证据，支撑后续审计、复盘和变更管理。
这五类目的中，缺陷预防和风险控制在自动化项目中权重最高，因为现场调试成本远高于桌面修改成本。
二、三种典型评审类型
业界常把评审分为同行评审、走查和审查。三者在正式程度、参与角色和适用场景上有明显差异，自动化项目应根据风险等级选择。
| 类型 | 正式程度 | 主要形式 | 适用场景 | 输出物 |
|---|---|---|---|---|
| 同行评审 | 中 | 作者提交合并请求，1～2 名同行在线评论 | 日常功能模块、非安全关键逻辑 | 评论记录、修改后合入 |
| 走查 | 中低 | 作者讲解，参与者提问并记录问题 | 新成员代码、复杂算法、接口设计 | 问题清单、改进建议 |
| 审查 | 高 | 按检查表逐项核对，指定角色签字 | 安全逻辑、急停回路、量产发布前 | 审查报告、缺陷统计、签字确认 |
需要强调的是，三者不是互斥关系。一个安全相关的 PLC 功能块，可以先做同行评审，再在发布前进行正式审查。
三、常见术语与判断标准
评审过程中经常出现一些术语，理解它们有助于统一团队语言：
- 缺陷（Defect）：代码未满足需求或规范，可能导致错误行为。
- 异味（Smell）：不一定立即出错，但暗示可维护性差，如重复代码、过长函数。
- 阻断项（Blocker）：必须修复才能合入的问题，如安全逻辑缺失。
- 建议项（Suggestion）：可优化但不影响当前功能，如命名改进。
- 检查表（Checklist）：评审时逐项核对的条目集合，是审查的核心工具。
四、评审在自动化项目中的重要性
自动化项目具有三个显著特点：软硬件耦合、现场不可逆、安全责任重。这决定了代码评审的价值远高于普通业务系统。
第一，自动化代码经常与传感器、执行器、机器人、视觉系统交互。一个未处理的超时分支，可能导致设备等待到死机。第二，很多逻辑一旦下载到控制器，现场调试需要停机窗口，修复成本极高。第三，安全逻辑必须经过独立验证，评审是形成证据链的重要环节。
下面这张图展示了自动化项目中代码评审的典型位置与信息流：从需求与设计出发，经过开发、评审、修复、验证，最终进入发布与现场。评审不是单点动作，而是质量门禁。
五、案例：一次被评审拦下的“小问题”
某装配线项目中，工程师编写了一个托盘到位后的夹紧逻辑。代码在仿真中运行正常，作者认为可以直接下载。评审时，同行发现夹紧输出没有与“急停复位”状态做互锁，且夹紧超时后只报警不释放。虽然现场测试未必立刻触发，但一旦操作员在急停后复位，夹紧可能意外动作。
// 评审前（简化示意）
IF PartPresent THEN
ClampCmd := TRUE;
IF NOT ClampSensor THEN
Alarm := TRUE; // 仅报警，未处理输出
END_IF;
END_IF;
// 评审后
IF PartPresent AND EStopOK AND NOT ClampFault THEN
ClampCmd := TRUE;
ELSIF ClampTimeout THEN
ClampCmd := FALSE;
ClampFault := TRUE;
END_IF;这个案例说明：评审的价值不在于发现“编译错误”，而在于发现状态组合下的风险。这类问题往往只有熟悉现场的人才能快速识别。
六、常见误区与复盘
- 误区一：评审就是挑错。如果语气对立，作者会防御，评审效率下降。应聚焦代码，不评价个人。
- 误区二：只看代码，不看需求。没有需求对照，无法判断逻辑是否完整。评审前应提供需求或设计说明。
- 误区三：评审通过等于验证完成。评审不能替代仿真、单元测试和现场验证，它只是质量门禁之一。
- 误区四：没有检查表，凭感觉评审。检查表能显著降低遗漏率，尤其是安全相关项。
总结来说，代码评审在自动化项目中是连接开发与发布的必要环节。理解其定义、目的和三种类型，掌握常见术语与判断标准，并建立适合团队风险的评审机制，才能让评审真正成为质量屏障，而不是流程负担。