项目标题: 技术选型系列文章二下从“选完”到“开干”——我的 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”而是对每个关键决策点都列了四段信息问题背景当时为什么需要做这个决策影响范围是什么候选方案比较过哪些方案各自的核心优势和劣势验证过程做了哪些实验或调研数据结论是什么决策结论保留意见最终选了什么以及“如果后续出现什么情况这个决策可能需要被推翻”。这种写法的好处是评审人不需要自己从零开始理解上下文直接看“保留意见”那一栏就能找到发起挑战的切入点。比如我在数据库方案的保留意见里写了一句“如果未来设备数量超过 200 台当前时序库的单节点部署模式可能需要引入集群方案”评审现场立刻有人就着这个话题追问了扩容路径的具体设计这在传统的“结论式评审”里几乎不可能发生。评审文档不是给领导看的成品它是一份邀请别人来挑刺的“半成品”这个心态必须摆正。2.2 技术决策记录每个选择都要有背景和备选写决策记录的时候最忌讳的就是只写结论不写过程。HomeSense 的决策记录里我特别强调一个原则任何一条决策都必须能回答“为什么不选另一个”。比如消息通信方案决策记录里写的是“选 MQTT 而非 HTTP 长轮询弱网下重连机制更成熟、消息推送实时性更好、生态里有成熟 broker 可用但 MQTT 的缺点是调试时需要额外工具且 broker 本身是个需要维护的组件”。这一条看起来简单但它逼着我在下笔的时候重新审视了一遍自己的选择确认我不是因为“大家都在用”才选的 MQTT。另外一个容易被忽略的点是决策记录必须包含“决策日期”和“决策人”。不是追责而是为了将来回看的时候能知道当时的思考是基于什么上下文。如果半年后某个决策被证明是错的一份带背景的决策记录能帮你快速定位是判断失误还是当初的信息不足这种复盘价值在长线项目里非常重要。HomeSense 最终决策记录的目录大概长这样设备端固件语言与 RTOS 选择设备与服务端的通信协议数据存储方案时序库 关系库的组合服务端开发框架与部署方式前端技术栈与构建工具项目管理与监控方案每一个条目都不长但每条都保持了“背景-候选-验证-结论-保留意见”的完整结构。这份文档前后花了我大概四个小时但它直接让评审会议的讨论质量提升了一个量级我觉得非常值。2.3 评审议题清单从功能验证到故障预案评审现场环节我列了一个议题清单确保每个关键维度都有人过问。这个清单本身也是经验沉淀下来的第一版只有“功能是否满足”“性能是否达标”两项后来发现漏掉的问题太多了现在固定成六个维度功能完整性选型方案是否覆盖了所有核心需求有没有靠“后续再说”蒙混过去的点性能与容量在预期负载下有没有余量有没有明确的扩容路径可维护性团队成员上手成本、文档生态、社区活跃度、故障排查时的可观测性安全与隐私家庭场景下设备数据和用户隐私的边界敏感信息的传输和存储方式成本金钱时间依赖的组件是否有商业授权风险部署所需的服务器资源以及团队学习成本风险与回退如果方案落地过程中出现严重问题是否具备可执行的回退路径。评审现场,大家围绕“如果 broker 挂了怎么办”这个问题讨论得最激烈。我当时的第一反应是“broker 有自动重连机制问题不大”但评审里有人追问“如果 broker 所在的服务整个宕机设备端的数据怎么办”这个问题直接把讨论引向了故障预案设计。最后我们讨论出一个简单的方案broker 和核心服务部署在同一台服务器的不同容器里由进程管理器统一守护同时设备端在本地保存最近多少条未确认数据等 broker 恢复后能自动续传。这个设计不算复杂但如果没有评审时的逼问大概率会变成上线后才暴露的事故。3. 风险清单与回退策略评审现场最该聊透的事3.1 我整理的风险清单可直接抄执行前评审里最容易走过场的就是风险讨论。大家都会说“风险可控”“有问题再解决”但这些话没有约束力。我在 HomeSense 这次评审里整理了成文的风险清单每条都标注了发生概率、影响程度和应对策略。这里放一个简化的版本供大家参考风险项发生概率影响程度应对策略时序数据库在长时间运行后存储膨胀中高规划数据保留策略原始数据定期归档或降采样设备端固件 OTA 失败导致设备变砖低高固件分区设计双备份A/B 分区回滚机制MQTT broker 单点故障中高由进程管理器自动拉起设备端本地暂存未确认数据前端图表库在大量数据点下渲染卡顿中中后端聚合接口先行前端做数据降采样展示传感器数据上报频率过高导致服务端压力中中设备端支持动态调整采集周期服务端做写入限流团队成员对时序数据库查询语法不熟高低整理常用查询模板评审后安排一次内部分享逐条说明一下我怎么定级和处理。存储膨胀这条我参考了网上常见的时序数据库最佳实践按 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 的技术选型系列上中下三篇就算告一段落了。后面的开发记录会切到项目实战方向设备端固件怎么写、断线补传怎么实现、时序数据量的可视化怎么做。选型真正结束的时刻不是文档写完的那一刻也不是评审通过的那一刻而是第一行代码跑起来、第一块传感器数据出现在屏幕上的那一刻。希望这个系列的收尾过程与执行前评审的思路能给你自己的项目带来一些参考。