14-技术评审流程方案评审、架构评审、接口评审、固件适配评审技术评审到底是评审什么很多小微团队对技术评审的理解就是——开会几个人坐一起看看文档点个头散会。这种评审在CMMI3里是不及格的。技术评审Technical Review的本质是在代码写出来之前把技术风险拦住。一个功能如果方案选错了、架构设计不合理、接口定义有漏洞等代码写完测试才发现修复成本是评审阶段发现的好几倍甚至几十倍。在智慧农业和无人售货柜项目里我们落地了四类技术评审覆盖从需求到实现的各个关键节点。每类评审都有明确的输入、输出和Checklist不是走过场。评审的基本框架先说整体流程四类评审的通用框架是一致的评审发起 → 材料预读 → 评审会议 → 缺陷记录 → 修改确认 → 评审关闭几个关键原则材料提前发评审材料至少提前1天发给参与者会上不念PPT直接讨论问题参与人有门槛不是谁都能来评审核心评审人必须有相关领域经验缺陷分级发现问题分Critical/Major/Minor三级Critical不修复不能关闭评审闭环跟踪评审发现的问题要录入缺陷管理系统修改完要确认不能开完会就忘评审主持人由技术负责人担任不一定是写方案的那个人——写方案的人不能当裁判。四类评审详解一、方案评审这事能不能干怎么干方案评审发生在需求分析之后、详细设计之前。核心要回答三个问题1. 方案可行性需求说用户扫码开门后系统能在500ms内识别用户身份并授权开门。这个方案可行吗我们需要评估网络延迟小程序扫码 → 后端鉴权 → 安卓开门链路能不能压到500ms弱网场景4G信号差的时候怎么办要不要安卓端做离线鉴权缓存硬件能力瑞芯微RK3288的运算性能够不够串口指令下发到电磁锁的延迟是多少2. 技术选型比如商品识别方案是选重力传感器RFID组合还是上计算机视觉YOLO模型两种方案的成本、准确率、维护难度完全不同。方案评审要把选型依据说清楚选型对比表示例 ┌──────────────┬────────────┬────────────┬────────────┐ │ 维度 │ 重力RFID │ YOLO视觉 │ 混合方案 │ ├──────────────┼────────────┼────────────┼────────────┤ │ 识别准确率 │ 95% │ 92% │ 98% │ │ 单柜成本 │ ¥800 │ ¥1200 │ ¥1500 │ │ 开发周期 │ 2周 │ 4周 │ 5周 │ │ 后期维护 │ 低 │ 中 │ 中 │ └──────────────┴────────────┴────────────┴────────────┘ → 选定混合方案准确率优先3. 性能预估方案里必须给出性能预估不是拍脑袋。比如预计并发用户数、QPS、存储容量增长曲线。后端用SpringBoot搭SaaS50个商户、每商户10台柜机峰值QPS预估多少MySQL单库扛不扛得住Redis缓存策略怎么设计这些在方案阶段就要有初步结论。二、架构评审骨架稳不稳方案评审过了之后进入详细设计阶段产出架构设计文档然后走架构评审。架构评审关注的不是功能能不能实现而是非功能需求。架构图必须包含系统部署图、模块依赖图、数据流图。以无人售货柜SaaS为例小程序 ──HTTPS──→ Nginx ──→ SpringBoot API ├──→ MySQL业务数据 ├──→ Redis缓存/会话 ├──→ MQTT Broker ──→ 安卓工控端 └──→ 对象存储商品图片 安卓工控端 ├── 传感器采集温湿度/重力/门磁 ├── 本地业务逻辑离线降级 └── MQTT上报 ──→ 后端非功能需求检查架构评审的核心Checklist检查项评审要点高可用单点故障在哪MySQL挂了怎么办MQTT Broker宕机柜子还能开门吗可扩展从50台柜机扩到500台架构需不需要改SaaS多租户隔离方案是否到位安全性API鉴权方案设备身份认证敏感数据加密防刷策略性能慢查询预防N1问题MQTT消息积压处理可运维日志采集方案监控告警链路追踪扩展性是重点。小微团队最怕的就是架构写死业务一变就得重构。比如最初只做无人售货柜后面要加智慧农业的大棚监控架构能不能平滑扩展这些在评审时就得问。三、接口评审契约靠不靠谱接口评审在API First流程中是核心环节上一篇讲过。接口契约一旦冻结三端就基于它并行开发所以评审必须严格。API契约检查检查项 □ URL路径符合RESTful规范/api/v1/cabinets/{id}/doors □ HTTP方法语义正确GET查询/POST创建/PUT更新/DELETE删除 □ 请求参数有类型、是否必填、取值范围说明 □ 响应结构统一{code, message, data} □ 错误码体系完整业务错误码 vs HTTP状态码 □ 分页参数统一page/pageSize/total □ 时间格式统一ISO 8601 或时间戳 □ 枚举值有明确列表兼容性检查接口变更是联调翻车的高发区。评审时必须确认新增字段是否向后兼容新增字段用可选不能改成必填删除字段的影响范围三端是否都已完成适配版本管理策略/api/v1/ vs /api/v2/什么时候升版本安全性检查敏感字段是否脱敏返回手机号、身份证号是否有越权风险用户A能不能查到用户B的订单接口限流策略防止恶意刷接口四、固件适配评审硬件这关过得去吗这是我们在智慧农业和无人售货柜项目中特有的评审类型因为涉及嵌入式硬件出问题的代价特别大——固件刷错可能导致设备变砖。硬件兼容性检查检查项 □ 目标硬件型号清单RK3288/RK3568/STM32F4 □ Linux内核版本兼容性 □ 安卓系统版本Android 7/9/11 □ 驱动依赖清单串口驱动/USB驱动/GPIO驱动 □ 外设兼容性传感器型号/电磁锁/摄像头/显示屏驱动适配检查传感器换了型号怎么办比如原来用HC-SR04超声波测距换成TOF激光测距驱动层怎么适配我们的做法是在安卓工控层做硬件抽象层HAL上层业务逻辑不直接调驱动而是调HAL接口。固件适配评审要确认HAL的设计是否合理。OTA方案评审固件OTA远程升级是最容易出事的环节。评审要点A/B分区方案升级失败能不能自动回滚到上一个版本断电保护升级过程中断电设备能不能恢复正常启动增量更新 vs 全量更新差分包大小升级耗时带宽消耗灰度策略先升级5台柜机观察24小时无异常再全量推送回滚机制发现新版本有问题能不能远程触发回滚评审Checklist模板汇总四类评审的Checklist要落地成文档每次评审对照打勾。我们用的模板结构## 评审信息 - 评审类型方案/架构/接口/固件适配 - 评审对象XXX功能 - 评审日期YYYY-MM-DD - 评审人XXX、XXX、XXX - 主持人XXX ## Checklist | 序号 | 检查项 | 结果(通过/不通过/N/A) | 备注 | |------|--------|----------------------|------| | 1 | ... | | | ## 缺陷记录 | 序号 | 级别 | 描述 | 负责人 | 状态 | |------|------|------|--------|------| | 1 | Major| ... | XXX | 待修复| ## 评审结论 □ 通过 □ 有条件通过修复Major后通过 □ 不通过重新评审小结技术评审是CMMI3里验证实践域的核心活动。四类评审各管一段方案评审管方向、架构评审管骨架、接口评审管契约、固件适配评审管硬件。评审不是为了挑刺而是把问题消灭在代码之前。小微团队人少评审可以轻量但不能没有。