13-三端并行开发规范后端SaaS、安卓工控、小程序协同开发模型为什么需要三端并行先说个真实的坑。我们做无人售货柜项目那会儿后端、安卓、小程序三端各干各的后端写完接口才丢个文档给前端安卓那边硬件调了半天发现接口字段对不上小程序又等安卓联调完才开工。结果一个本来两周能搞定的功能硬拖了一个月。问题出在哪没有协同模型。三端并行开发的核心不是同时开工这么简单而是要让三个团队在同一个节奏里跳舞谁先迈步、谁等谁、出了问题怎么升级都得提前定好规矩。在智慧农业和无人零售的场景里我们的典型三端架构是这样的后端SaaSJava SpringBoot提供API服务、业务逻辑、数据持久化安卓工控端运行在瑞芯微/STM32硬件上负责设备控制、传感器采集、本地业务小程序端用户侧入口商品浏览、扫码开门、支付结算三端各自技术栈差异大开发节奏也不同必须有一套协同模型来约束。协同模型API First 分阶段并行核心原则接口契约驱动开发整个协同模型的核心就一句话接口先行契约不可破坏。具体来说后端在写任何业务代码之前先把API接口定义清楚——包括URL路径、请求方法、入参字段、响应结构、错误码——然后用Swagger/OpenAPI生成文档丢到API管理平台上。安卓和小程序拿到接口契约后就可以用Mock数据并行开发了不用等后端把逻辑写完。这套流程叫API First在CMMI3里属于技术方案评审的一部分。它的好处很明显后端被迫提前思考接口设计避免写到一半发现字段不够用前端安卓/小程序不阻塞拿到Mock就能干活接口契约一旦冻结任何一方改动必须走变更流程三阶段并行节奏我们把一个迭代周期通常两周分成三个阶段阶段一接口定义1-2天 ├── 后端输出API契约文档 Mock服务 ├── 安卓评审接口契约确认硬件相关字段 └── 小程序评审接口契约确认页面数据需求 阶段二并行开发7-8天 ├── 后端实现业务逻辑 单元测试 ├── 安卓基于Mock开发UI 硬件适配 └── 小程序基于Mock开发页面 交互逻辑 阶段三联调收尾2-3天 ├── 后端切换到真实环境配合联调 ├── 安卓硬件真机联调 边界测试 └── 小程序真机预览 体验版验证关键点在阶段一接口评审必须三端都参加。安卓要确认硬件采集的数据字段是否齐全比如柜门状态、温湿度、商品重量小程序要确认页面渲染所需的数据结构是否够用。后端不能闭门造车否则定义出来的接口必然返工。每日站会同步机制站会不是走过场很多团队的站会就是三个人轮流说昨天写了啥、今天写啥说完散会啥问题也暴露不出来。我们在CMMI3落地时对站会做了约束效果好了不少。站会的核心目的只有一个暴露阻塞。所以我们的站会格式是这样的每人三句话 1. 昨天完成了什么具体到功能点 2. 今天计划做什么 3. 有没有阻塞有→立即升级无→过三端阻塞的三种典型场景场景一接口变更引发阻塞安卓开发到一半发现后端某个接口缺了个字段。按规矩不能直接找后端改得先走变更流程在接口管理平台提Issue说明变更原因和影响范围后端评估是否影响小程序端如果影响三端同步确认后再改接口契约更新版本号三端各自适配场景二硬件联调阻塞安卓端在真机调试时发现瑞芯微板子的串口通信有延迟导致扫码开门响应慢。这种问题不是后端能帮忙的但站会上说出来后项目负责人可以协调嵌入式组的同事支援。场景三数据依赖阻塞小程序要展示销售报表但后端的统计接口还没开发完。站会上暴露后后端优先调整开发顺序先把统计接口的Mock数据补上让小程序先跑通流程。阻塞问题快速升级流程小微团队最怕的就是问题闷着不说拖到交付才爆雷。我们定了一个简单的升级规则阻塞时长 升级级别 处理人 ───────────────────────────────────────── 2小时 不升级 自行解决 2-4小时 L1 - 项目组长 协调资源 4-8小时 L2 - 项目经理 介入决策 8小时 L3 - 技术负责人 方案调整 1天 L4 - 紧急会议 可能影响交付这个表贴在项目看板上所有人都能看到。关键是升级不等于追责升级是为了快速解决问题不是为了甩锅。团队文化得跟得上不然没人愿意主动升级。联调环境搭建与数据准备联调环境的三层架构联调是最容易翻车的环节。我们的联调环境分三层第一层本地联调环境每个开发者在本地跑一套完整的后端服务 MySQL Redis。安卓和小程序连本地后端调试速度最快适合接口级别联调。第二层共享联调环境Staging部署在内网服务器上三端共用一套环境。后端代码合并到develop分支后自动部署到Staging安卓和小程序切到Staging环境测试。这层环境主要验证三端集成后的业务流程是否跑通。第三层硬件联调环境专门搭一间设备房放几台真实的无人售货柜安卓工控板装在柜子里连着真实的传感器和锁。三端联调到这层验证完整闭环小程序扫码 → 安卓开门 → 用户取货 → 传感器识别 → 后端扣款。数据准备清单联调最烦的不是代码是数据。每次联调前我们按这个清单准备数据类型准备内容负责人用户数据测试账号管理员/普通用户/游客后端商品数据至少20个SKU含图片和价格运营设备数据柜机编号、货道映射、传感器配置安卓订单数据模拟订单待支付/已完成/退款后端异常数据断网场景、库存不足、传感器离线安卓后端异常数据特别重要。正常流程谁都能跑通但断网了怎么办传感器读数异常怎么办这些边界场景才是联调的重点也是CMMI3里验证与确认要求覆盖的。协同开发的技术工具链光有流程不够还得有工具落地。我们用的工具链接口管理YApi开源支持Mock、自动化测试、版本管理代码协作GitLabdevelop分支为集成分支feature分支开发CI/CDGitLab CI后端push到develop自动部署Staging即时沟通企业微信群 机器人通知接口变更自动推送任务看板Jira或Trello站会基于看板过任务工具不在多在于团队真正用起来。小微团队最怕的是上了五个工具没人维护最后还是靠口头沟通。小结三端并行开发的核心不是并行而是协同。接口契约是三端的共同语言阶段划分是三端的共同节奏站会升级是三端的共同保险。把这三件事做到位后端SaaS、安卓工控、小程序三端就能真正跑起来而不是各自为战、联调翻车。下一篇我们会聊技术评审——这是保证三端协同质量的另一道关键闸门。
13-三端并行开发规范后端SaaS、安卓工控、小程序协同开发模型为什么需要三端并行先说个真实的坑。我们做无人售货柜项目那会儿后端、安卓、小程序三端各干各的后端写完接口才丢个文档给前端安卓那边硬件调了半天发现接口字段对不上小程序又等安卓联调完才开工。结果一个本来两周能搞定的功能硬拖了一个月。问题出在哪没有协同模型。三端并行开发的核心不是同时开工这么简单而是要让三个团队在同一个节奏里跳舞谁先迈步、谁等谁、出了问题怎么升级都得提前定好规矩。在智慧农业和无人零售的场景里我们的典型三端架构是这样的后端SaaSJava SpringBoot提供API服务、业务逻辑、数据持久化安卓工控端运行在瑞芯微/STM32硬件上负责设备控制、传感器采集、本地业务小程序端用户侧入口商品浏览、扫码开门、支付结算三端各自技术栈差异大开发节奏也不同必须有一套协同模型来约束。协同模型API First 分阶段并行核心原则接口契约驱动开发整个协同模型的核心就一句话接口先行契约不可破坏。具体来说后端在写任何业务代码之前先把API接口定义清楚——包括URL路径、请求方法、入参字段、响应结构、错误码——然后用Swagger/OpenAPI生成文档丢到API管理平台上。安卓和小程序拿到接口契约后就可以用Mock数据并行开发了不用等后端把逻辑写完。这套流程叫API First在CMMI3里属于技术方案评审的一部分。它的好处很明显后端被迫提前思考接口设计避免写到一半发现字段不够用前端安卓/小程序不阻塞拿到Mock就能干活接口契约一旦冻结任何一方改动必须走变更流程三阶段并行节奏我们把一个迭代周期通常两周分成三个阶段阶段一接口定义1-2天 ├── 后端输出API契约文档 Mock服务 ├── 安卓评审接口契约确认硬件相关字段 └── 小程序评审接口契约确认页面数据需求 阶段二并行开发7-8天 ├── 后端实现业务逻辑 单元测试 ├── 安卓基于Mock开发UI 硬件适配 └── 小程序基于Mock开发页面 交互逻辑 阶段三联调收尾2-3天 ├── 后端切换到真实环境配合联调 ├── 安卓硬件真机联调 边界测试 └── 小程序真机预览 体验版验证关键点在阶段一接口评审必须三端都参加。安卓要确认硬件采集的数据字段是否齐全比如柜门状态、温湿度、商品重量小程序要确认页面渲染所需的数据结构是否够用。后端不能闭门造车否则定义出来的接口必然返工。每日站会同步机制站会不是走过场很多团队的站会就是三个人轮流说昨天写了啥、今天写啥说完散会啥问题也暴露不出来。我们在CMMI3落地时对站会做了约束效果好了不少。站会的核心目的只有一个暴露阻塞。所以我们的站会格式是这样的每人三句话 1. 昨天完成了什么具体到功能点 2. 今天计划做什么 3. 有没有阻塞有→立即升级无→过三端阻塞的三种典型场景场景一接口变更引发阻塞安卓开发到一半发现后端某个接口缺了个字段。按规矩不能直接找后端改得先走变更流程在接口管理平台提Issue说明变更原因和影响范围后端评估是否影响小程序端如果影响三端同步确认后再改接口契约更新版本号三端各自适配场景二硬件联调阻塞安卓端在真机调试时发现瑞芯微板子的串口通信有延迟导致扫码开门响应慢。这种问题不是后端能帮忙的但站会上说出来后项目负责人可以协调嵌入式组的同事支援。场景三数据依赖阻塞小程序要展示销售报表但后端的统计接口还没开发完。站会上暴露后后端优先调整开发顺序先把统计接口的Mock数据补上让小程序先跑通流程。阻塞问题快速升级流程小微团队最怕的就是问题闷着不说拖到交付才爆雷。我们定了一个简单的升级规则阻塞时长 升级级别 处理人 ───────────────────────────────────────── 2小时 不升级 自行解决 2-4小时 L1 - 项目组长 协调资源 4-8小时 L2 - 项目经理 介入决策 8小时 L3 - 技术负责人 方案调整 1天 L4 - 紧急会议 可能影响交付这个表贴在项目看板上所有人都能看到。关键是升级不等于追责升级是为了快速解决问题不是为了甩锅。团队文化得跟得上不然没人愿意主动升级。联调环境搭建与数据准备联调环境的三层架构联调是最容易翻车的环节。我们的联调环境分三层第一层本地联调环境每个开发者在本地跑一套完整的后端服务 MySQL Redis。安卓和小程序连本地后端调试速度最快适合接口级别联调。第二层共享联调环境Staging部署在内网服务器上三端共用一套环境。后端代码合并到develop分支后自动部署到Staging安卓和小程序切到Staging环境测试。这层环境主要验证三端集成后的业务流程是否跑通。第三层硬件联调环境专门搭一间设备房放几台真实的无人售货柜安卓工控板装在柜子里连着真实的传感器和锁。三端联调到这层验证完整闭环小程序扫码 → 安卓开门 → 用户取货 → 传感器识别 → 后端扣款。数据准备清单联调最烦的不是代码是数据。每次联调前我们按这个清单准备数据类型准备内容负责人用户数据测试账号管理员/普通用户/游客后端商品数据至少20个SKU含图片和价格运营设备数据柜机编号、货道映射、传感器配置安卓订单数据模拟订单待支付/已完成/退款后端异常数据断网场景、库存不足、传感器离线安卓后端异常数据特别重要。正常流程谁都能跑通但断网了怎么办传感器读数异常怎么办这些边界场景才是联调的重点也是CMMI3里验证与确认要求覆盖的。协同开发的技术工具链光有流程不够还得有工具落地。我们用的工具链接口管理YApi开源支持Mock、自动化测试、版本管理代码协作GitLabdevelop分支为集成分支feature分支开发CI/CDGitLab CI后端push到develop自动部署Staging即时沟通企业微信群 机器人通知接口变更自动推送任务看板Jira或Trello站会基于看板过任务工具不在多在于团队真正用起来。小微团队最怕的是上了五个工具没人维护最后还是靠口头沟通。小结三端并行开发的核心不是并行而是协同。接口契约是三端的共同语言阶段划分是三端的共同节奏站会升级是三端的共同保险。把这三件事做到位后端SaaS、安卓工控、小程序三端就能真正跑起来而不是各自为战、联调翻车。下一篇我们会聊技术评审——这是保证三端协同质量的另一道关键闸门。
