技术选型收尾与执行前评审：从决策记录到垂直切片落地实践

项目标题: "技术选型系列文章（二下）：从“选完”到“开干”——我的 HomeSense 技术选型收尾与执行前评审"

上一篇文章我还在纠结 HomeSense 的几组技术对比，这篇直接聊聊收尾阶段的事。技术选型这件事，真正难的往往不是选哪个，而是什么时候停止选、选完之后怎么让团队（或者你自己）相信这个结论经得起推敲。这篇文章的核心就是“收尾”和“执行前评审”这两个动作，我会把 HomeSense 最终定下来的技术栈、评审时踩过的坑、以及从文档到代码之间的那段过渡期怎么安排，全部摊开来讲。

文章适合正在做技术选型但是迟迟收不了尾的人，也适合那种选完了但心里没底、总觉得要再比一比的人。我会尽量把“怎么判断选型可以结束”“评审到底审什么”“怎么把评审结论转成开发计划”这三件事说透。

1. 选型收尾：当“再比较一下”变成一种拖延

1.1 收尾信号：什么状态才算“可以定稿了”

我见过不少人，包括我自己早期做项目的时候，技术选型能做到“永远差一步”——总是觉得还有个方案没比较、还有个benchmark没跑、还有个极端场景没验证。理论上这没错，但工程进度不会等你把每个分支都探索完。HomeSense 这个项目走到这个阶段，我给自己定了一个非常明确的收尾判据：当所有核心决策点都已经有至少两个候选方案做过验证，并且验证结果没有出现颠覆性差异时，选型必须结束。

什么叫核心决策点？我分成三类：

• 直接影响架构形态的决策，比如设备端到服务端的通信协议、数据存储方案。这类决策一旦定了，后期改动成本极高，必须反复确认。
• 影响开发效率但可替换的决策，比如前端框架、ORM 选型。这类决策错了可以局部重写，负担相对可控。
• 影响部署运维方式的决策，比如容器化方案、日志收集方式。这类决策决定了项目跑起来之后的维护体验。

在收尾阶段，我的建议是：只对第一类决策保持“零容忍确认”，对第二类和第三类，达到“能满足当前需求且没有致命问题”就可以定稿。HomeSense 的通信协议我在 MQTT 和 HTTP 长轮询之间纠结了比较久，最后用了一个周末写了个模拟设备脚本，分别压了两种方案在弱网环境下的表现，确认 MQTT 确实在断线重连和消息实时性上有明显优势，这个点就算封板了。至于前端用 Vue 还是 React，我评估了团队成员的技术背景和维护成本之后，选了 Vue，原因很简单——够用，且团队上手最快，没必要为了技术热度给自己挖坑。这两个决策一重一轻，处理方式完全不同，但都用了同一个逻辑：先定义“验证到什么程度就算够了”。

1.2 最后一轮验证实验：用最小成本消除最大不确定性

选型收尾前，我习惯做一轮“定向验证”，不是全面铺开测，而是只针对那些犹豫最久的点做最小实验。HomeSense 最后剩下的最大不确定是两个：

一是数据库方案。设备采集的温湿度、空气质量数据是典型的时间序列数据，量级不大但写入频繁，而且查询模式都是按时间段聚合。我在 MySQL 和时序数据库之间犹豫，是因为 HomeSense 的并发量其实很小，MySQL 完全扛得住，但时序数据库在查询聚合上确实更顺手。为了验证差距到底有多大，我用 Docker 起了两个环境，分别灌入模拟生成的三个月数据（约 20 万条记录），跑了几个典型查询，比如“过去24小时每小时平均温度”和“最近一周空气质量超标的时段分布”。实测结果两者差异没那么悬殊，MySQL 加个合理索引也能在百毫秒内返回，但时序数据库的查询语法明显更贴合这类需求，少写了不少代码。于是最终选了时序方案，理由不是性能碾压，而是“更少的代码维护成本和更自然的查询表达”。

二是设备端的网络断线处理。HomeSense 的设备节点分布在家庭各个角落，Wi-Fi 不稳定是常态，设备采集到数据后如果直接往服务端发，网络抖动就会丢数据。我之前在“设备本地暂存+定期补传”和“依赖 MQTT QoS 1 保证送达”之间犹豫。最后一轮验证里，我写了个模拟脚本，人为制造随机断网，对比两种方案的数据完整率。结论是 MQTT QoS 1 在 broker 持久化会话的配合下，已经能很好解决断线补传的问题，完全没必要在设备端自己维护一套本地缓存逻辑。这个验证帮我砍掉了一个原本计划中的组件，直接简化了设备端代码。

最后一轮验证的原则是：只测那些影响结论的点，并且设定明确的“通过/不通过”标准再开始跑，不然很容易陷入“跑完发现数据有意思，再跑一组”的循环里出不来。我当时给自己定的标准就是：如果某个方案在核心指标上有 30% 以上的优势且不引入明显复杂度，就值得选；如果差距在 30% 以内，选维护成本低的那一个。

2. 执行前评审：不是走流程，而是给方案挑刺

2.1 评审材料：把零散结论整理成可质疑的文档

很多项目的执行前评审都是“PPT 汇报制”——选型的人把结论讲一遍，其他人听一遍，然后鼓掌通过。这种评审最大的问题是：结论背后的决策过程没有暴露出来，其他人想提反对意见都不知道从哪个角度切入。HomeSense 这次评审，我没有走这个形式，而是提前三天把一份《技术决策记录》文档发给了所有参与评审的人。

这份文档和通常的“技术方案说明书”有点区别，它不写“我们选了 A”，而是对每个关键决策点都列了四段信息：

1. 问题背景：当时为什么需要做这个决策，影响范围是什么；
2. 候选方案：比较过哪些方案，各自的核心优势和劣势；
3. 验证过程：做了哪些实验或调研，数据结论是什么；
4. 决策结论+保留意见：最终选了什么，以及“如果后续出现什么情况，这个决策可能需要被推翻”。

这种写法的好处是，评审人不需要自己从零开始理解上下文，直接看“保留意见”那一栏就能找到发起挑战的切入点。比如我在数据库方案的保留意见里写了一句“如果未来设备数量超过 200 台，当前时序库的单节点部署模式可能需要引入集群方案”，评审现场立刻有人就着这个话题追问了扩容路径的具体设计，这在传统的“结论式评审”里几乎不可能发生。评审文档不是给领导看的成品，它是一份邀请别人来挑刺的“半成品”，这个心态必须摆正。

2.2 技术决策记录：每个选择都要有背景和备选

写决策记录的时候，最忌讳的就是只写结论不写过程。HomeSense 的决策记录里，我特别强调一个原则：任何一条决策，都必须能回答“为什么不选另一个”。比如消息通信方案，决策记录里写的是“选 MQTT 而非 HTTP 长轮询：弱网下重连机制更成熟、消息推送实时性更好、生态里有成熟 broker 可用；但 MQTT 的缺点是调试时需要额外工具，且 broker 本身是个需要维护的组件”。这一条看起来简单，但它逼着我在下笔的时候重新审视了一遍自己的选择，确认我不是因为“大家都在用”才选的 MQTT。

另外一个容易被忽略的点是：决策记录必须包含“决策日期”和“决策人”。不是追责，而是为了将来回看的时候，能知道当时的思考是基于什么上下文。如果半年后某个决策被证明是错的，一份带背景的决策记录能帮你快速定位是判断失误还是当初的信息不足，这种复盘价值在长线项目里非常重要。

HomeSense 最终决策记录的目录大概长这样：

• 设备端固件语言与 RTOS 选择
• 设备与服务端的通信协议
• 数据存储方案（时序库 + 关系库的组合）
• 服务端开发框架与部署方式
• 前端技术栈与构建工具
• 项目管理与监控方案

每一个条目都不长，但每条都保持了“背景-候选-验证-结论-保留意见”的完整结构。这份文档前后花了我大概四个小时，但它直接让评审会议的讨论质量提升了一个量级，我觉得非常值。

2.3 评审议题清单：从功能验证到故障预案

评审现场环节，我列了一个议题清单，确保每个关键维度都有人过问。这个清单本身也是经验沉淀下来的，第一版只有“功能是否满足”“性能是否达标”两项，后来发现漏掉的问题太多了，现在固定成六个维度：

• 功能完整性：选型方案是否覆盖了所有核心需求，有没有靠“后续再说”蒙混过去的点；
• 性能与容量：在预期负载下有没有余量，有没有明确的扩容路径；
• 可维护性：团队成员上手成本、文档生态、社区活跃度、故障排查时的可观测性；
• 安全与隐私：家庭场景下设备数据和用户隐私的边界，敏感信息的传输和存储方式；
• 成本（金钱+时间）：依赖的组件是否有商业授权风险，部署所需的服务器资源，以及团队学习成本；
• 风险与回退：如果方案落地过程中出现严重问题，是否具备可执行的回退路径。

评审现场,大家围绕“如果 broker 挂了怎么办”这个问题讨论得最激烈。我当时的第一反应是“broker 有自动重连机制，问题不大”，但评审里有人追问“如果 broker 所在的服务整个宕机，设备端的数据怎么办”，这个问题直接把讨论引向了故障预案设计。最后我们讨论出一个简单的方案：broker 和核心服务部署在同一台服务器的不同容器里，由进程管理器统一守护，同时设备端在本地保存最近多少条未确认数据，等 broker 恢复后能自动续传。这个设计不算复杂，但如果没有评审时的逼问，大概率会变成上线后才暴露的事故。

3. 风险清单与回退策略：评审现场最该聊透的事

3.1 我整理的风险清单（可直接抄）

执行前评审里最容易走过场的就是风险讨论。大家都会说“风险可控”“有问题再解决”，但这些话没有约束力。我在 HomeSense 这次评审里整理了成文的风险清单，每条都标注了发生概率、影响程度和应对策略。这里放一个简化的版本，供大家参考：

逐条说明一下我怎么定级和处理。存储膨胀这条，我参考了网上常见的时序数据库最佳实践，按 HomeSense 的采集频率粗算了一下：每小时 6 次采集、每天 24 小时、每节点 6 个传感器，一年下来单节点的原始数据量也没有想象中恐怖。但为了保险起见，我还是定了“保留原始数据 6 个月 + 超过 6 个月的降采样为小时均值”的策略。OTA 变砖这个风险，源于智能硬件项目里最怕的就是“设备寄回来刷固件”，所以 A/B 分区是必须的，不是因为设备有多贵，而是因为上门维护的时间成本太高了。

3.2 回退条件与触发机制：什么情况才算“必须回退”

风险清单之后，还要明确回退策略。回退不是认输，是工程上的正常操作，但必须提前定义清楚：什么条件触发回退、回退到哪个版本、回退需要多长时间。HomeSense 的决策记录里，我为三个核心组件各自写了回退方案。

数据库这块，如果时序方案在集成测试阶段暴露出写入性能问题或者查询语法严重拖慢开发效率，回退路径是“切换回 MySQL + 定时任务做聚合统计”。因为数据模型在设计的时候，我特意保持了两者之间的表结构映射关系，所以切换成本被控制在了两个工作日内。这不是事后补救，而是在做时序方案测试时就同步维护了一套 DDL 脚本，确保回退路径是一直可用的。

设备端通信这块，如果 MQTT 方案在家庭网络环境里频繁出现断连且无法自愈，回退路径是“改为 HTTP 批量上报+服务端提供补偿接口”。设备端代码里把消息发送抽象成独立模块，MQTT 和 HTTP 只是两种实现，后续替换不需要动业务逻辑。

前端这块，如果选定的图表库在真实数据量下渲染性能不达标，回退路径是“换成 Canvas 绘制的自研图表组件”，但这条回退的成本比较高，所以我在评审里明确它是在前两条之后最后才考虑的。回退策略的关键不在于方案本身多完美，而在于它能不能快速执行。如果一条回退路径需要重新设计整个架构才能执行，那它就不是回退，是重构。

4. 从评审到开工：把结论变成第一个里程碑

4.1 第一里程碑：垂直切片而非水平分层

评审通过之后，最容易犯的错误就是按技术分层安排开发计划——“先搭好数据库、再写后端接口、再做前端页面”。这种水平分层的计划看起来整齐，但实际上会导致项目在很长一段时间里没有可交付的成果，集成风险全部堆在后期爆发。

HomeSense 这次我换了个方式，第一里程碑做成一个垂直切片：从设备采集数据、通过 MQTT 上报、服务端接收落库、到前端页面展示实时温度曲线，整条链路跑通。这个切片不做得很深，不涉及用户系统、不涉及复杂报表，但必须覆盖项目里所有核心组件。做垂直切片有几个看得见的好处：

• 所有技术栈整合在一起真实跑过一遍，比任何单元测试都能反映集成问题；
• 团队成员能在第一周就看到一个“能用的东西”，而不是一堆“还在建的模块”，对士气和信心帮助很大；
• 任何组件之间的接口问题会在早期暴露，而这个阶段改代码的成本是最低的。

我把这个切片的目标写成一句话：“在局域网内，把任意一个温湿度传感器的数据，在 3 秒内展示到前端页面上。”这个目标足够小，但又横跨了所有核心环节。所谓“从选完到开干”，真正的开端就是把这个切片完成。

4.2 开工前的环境与规范准备

普通想法是先跑起来再说，但实际上，评审通过后的那几天是整理工程规范的最佳时间窗口。因为这个时候方案刚定、代码还没堆上去,改结构成本最低。HomeSense 这个阶段的整理包括三件事：

• 仓库结构：按“firmware（设备端）、server（服务端）、web（前端）、docs（文档）”划分多个子仓库。别小看这一步，如果一开始就混在一起，后面拆分的成本远超你的想象。文档单独一个仓库的好处是，技术决策记录、运维手册不会随着代码改动而丢失上下文。
• 环境标准化：所有后端依赖统一用容器编排管理，开发机和服务器的环境保持一致。HomeSense 的数据存储、消息服务、后端应用全部写在 compose 文件里，新成员加入时一条命令拉起全部依赖，省掉了大量“我本地明明是好的”这类古典问题。
• 提交规约：强制使用“类型(范围): 描述”的提交信息格式，例如feat(server): 新增历史数据聚合接口、fix(device): 修复断线补传的重试次数上限问题。这不是为了好看，而是后期生成变更日志和定位问题时，能直接从提交记录里过滤出某一类改动。配合代码规范检查工具和自动化测试，在开工第一天就把质量门禁立起来。第一周的“麻烦”能避免后面无数个“事故”。

4.3 首轮开发中的几个意外与应对

哪怕做了这么多准备，真正进入开发后还是会有意外。这里简单记录两个 HomeSense 垂直切片开发中遇到的问题，算是给这个系列的阶段性说明留一个注脚。

第一个是 MQTT 客户端的 session 过期问题。设备端默认使用了持久会话，但如果设备长时间离线超过了 broker 的会话过期时间，重新上线后订阅关系会丢失，表现为设备“在线但不上报数据”。排查这个问题的思路挺典型的：先确认设备确实连上了 broker（用调试工具能看到连接），再检查订阅关系是否存在，最后定位到 session 过期参数。解决办法是设备端在连接建立后主动重新订阅所有主题，而不是依赖 broker 侧的持久会话恢复机制。

第二个是时序数据库的时区问题。设备端上报的时间戳是本地时区，而服务端写入数据库用的是 UTC，导致前端按小时聚合的时候，数据整体偏移了 8 个小时。排查过程也很典型：单看原始数据感觉没问题，但一按小时分组就发现有规律的偏差，最后发现是时区处理不统一。解决办法是统一规定所有时间戳在传输层一律使用带时区信息的 ISO8601 格式，在数据库层统一转成 UTC 存储，前端展示时再转成本地时区。这两条问题都不是技术方案本身选错了，而是“方案落地时的边界细节”没考虑全，恰好就是执行前评审里最难预判的部分。

5. 评审不是终点：收尾文档与持续追踪

5.1 评审记录归档与待办闭环

评审会议的结束不代表这件事结束了，我在 HomeSense 的操作里会把会上的所有讨论项记录成一份待办清单，明确每一项负责人、截止日期、验证标准。比如“验证 broker 自动拉起机制是否真的能恢复服务”“补一个时区转换的说明文档”这类，都会在归档文档里列清楚。

一份评审记录如果没有闭环追踪，一个月后就会变成没人看的旧文件。我习惯的做法是：把评审待办放进项目的迭代管理中，和开发任务一起排期。评审提出的问题如果重要，就应该占用开发时间；如果不重要，那就不应该被提出来。这个规则反过来也约束了评审参与者——避免在会上提一堆不痛不痒、永远不跟进的意见。

5.2 技术选型文档的更新频率

技术选型文档不是一锤子买卖，HomeSense 的决策记录现在还在持续更新。真实世界里，一个新组件被引入、一个旧组件的性能瓶颈被验证，都会让你对当初的决策产生新的认知。我的更新原则是：当某个决策的实际表现和决策记录中的预期出现偏差时，必须回写文档。比如当时预期时序方案能减少聚合查询代码量，实际开发中如果发现查询语法依然有很高的学习成本，这个信息就应该被记录回来。这种回写不是否定当初的选择，而是让选型文档变成活的决策日志，而不是静态的、仅供参观的文档摆设。

5.3 后续计划

到这里，HomeSense 的技术选型系列（上中下三篇）就算告一段落了。后面的开发记录会切到项目实战方向：设备端固件怎么写、断线补传怎么实现、时序数据量的可视化怎么做。选型真正结束的时刻，不是文档写完的那一刻，也不是评审通过的那一刻，而是第一行代码跑起来、第一块传感器数据出现在屏幕上的那一刻。希望这个系列的收尾过程与执行前评审的思路，能给你自己的项目带来一些参考。