1. 代码审查总论：嵌入式C代码审查的目标、原则与流程概述

各位同行，咱们今天聊聊代码审查这件事。说实话，我做了十几年嵌入式开发，见过太多因为代码审查不到位而翻车的项目。有一次，一个同事在中断服务函数里调用了printf，审查时没人发现，结果产品在现场跑着跑着就死机了。嗯，从那以后，我对代码审查的态度就变得特别认真。

1.1 我们为什么要做代码审查？

说白了，代码审查不是为了找茬，而是为了省钱。你想想看，一个bug在编码阶段发现，改起来可能就几分钟。要是流片回来才发现，那代价可就大了去了。

我个人习惯把嵌入式C代码审查的目标归纳为三点：

• 发现缺陷：逻辑错误、边界条件、资源泄漏这些硬伤
• 保证规范：代码风格、命名规则、注释质量这些软实力
• 知识传递：让团队里每个人都理解这段代码为什么这么写

1.2 嵌入式C代码审查的特殊性

做嵌入式的人都知道，咱们的代码和纯软件不一样。我在项目中遇到过这样一个场景：一个看起来完全正确的C代码，放到ARM Cortex-M3上跑得好好的，换到M0上就出问题了。为什么？因为M0不支持某些指令，编译器悄悄做了替换。

嵌入式C代码审查需要特别关注以下几点：

审查维度	典型问题	我的经验
资源约束	栈溢出、堆碎片、内存泄漏	我曾经在审查时发现一个递归函数，递归深度超过栈空间，但测试时没触发
实时性	中断延迟、临界区过长、优先级反转	有个项目因为关中断时间太长，导致串口丢数据，审查时一眼就看出来了
硬件依赖	寄存器操作、位域对齐、volatile使用	volatile这个关键字，我见过至少十次因为漏写导致的诡异bug
可移植性	字节序、数据类型长度、编译器差异	int到底是16位还是32位？别猜，用里的类型

1.3 审查原则：少即是多

做审查这么多年，我总结出几条铁律：

1. 每次审查不超过400行代码。人的注意力是有限的，超过这个量，效果直线下降。我试过一次性审查2000行，结果后面1000行基本是白看。
2. 审查时间控制在60分钟以内。超过一小时，大脑就开始疲劳了。如果代码量大，分多次审查。
3. 作者先自审，再提交审查。我见过有人提交的代码连编译都不过，这不是浪费大家时间吗？
4. 审查者要理解代码，不只是看格式。格式问题交给工具去做，人应该关注逻辑和设计。

1.4 审查流程：从提交到关闭

一个标准的审查流程，我建议这样走：

1. 代码提交阶段
   - 开发者完成自审
   - 确保编译通过，静态检查无严重问题
   - 提交审查请求，附上变更说明

2. 审查分配阶段
   - 指定至少两名审查者
   - 确保审查者熟悉相关模块
   - 设置审查截止时间

3. 审查执行阶段
   - 审查者逐行阅读代码
   - 记录问题，分类标记（严重/一般/建议）
   - 与作者沟通确认问题

4. 问题修复阶段
   - 作者根据反馈修改代码
   - 对每个问题给出回应（已修复/无需修复并说明原因）
   - 重新提交审查

5. 审查关闭阶段
   - 审查者确认所有问题已处理
   - 签署审查通过
   - 归档审查记录

嗯，这里要注意一点：审查不是一次性的。如果修改后的代码变化很大，我建议重新审查一遍。别嫌麻烦，我吃过这个亏——有一次觉得「就改了几行」，结果那几行里藏着一个严重的竞态条件。

1.5 常见误区与避坑指南

这些年我踩过的坑，给大家列出来：

• 误区一：审查就是找bug。其实审查更重要的是发现设计缺陷和可维护性问题。bug迟早会被测试发现，但糟糕的设计会一直拖累项目。
• 误区二：审查越严格越好。我曾经见过一个审查者要求把所有的for循环改成while，理由是「for循环容易出错」。这种吹毛求疵只会让团队反感。
• 误区三：审查可以替代测试。千万别这么想！审查和测试是互补的，谁也替代不了谁。审查发现逻辑问题，测试验证功能正确。

1.6 审查的文化建设

最后说点软性的东西。代码审查能不能做好，很大程度上取决于团队文化。我见过一些团队，审查时火药味十足，作者和审查者吵得不可开交。这样搞下去，谁还愿意提交代码审查？

我个人建议：

• 审查时对事不对人，讨论代码而不是讨论写代码的人
• 审查者要给出建设性意见，不只是说「这里不对」
• 作者要保持开放心态，别把审查当成批评

说白了，代码审查是团队协作的一部分。你想想看，如果每个人都能从审查中学到东西，那这个团队的技术水平一定会越来越高。

好了，这一章就聊到这里。下一章咱们深入讲讲审查清单的具体内容，包括哪些问题必须查、哪些可以放一放。到时候我会拿几个真实的代码片段出来，咱们一起分析分析。