一家开了六家门店的健身房，把私教课时管起来一年多之后，提出要做安卓和 iOS 的 App。负责 IT 的同事拿着两年前那份小程序定制开发的报价单进来，第一句话是：小程序都做完了，App 是不是把代码拷过去改改就行。
问题一：现有代码里到底哪一部分能搬走
把仓库拉下来统计了一遍，整个项目十二万四千行代码，服务端五万六千行，小程序前端四万一千行，管理后台两万七千行。服务端那部分确实可以一行不改直接复用——课时账本、排课冲突校验、私教提成计提规则，这些跟端没有任何关系。前端四万一千行，能搬走的接近于零，小程序的组件、路由、生命周期换到别的端全部作废。
照代码量算，复用率是百分之四十五，这个数字拿去写方案很好看。但报价要按人天算，不能按行数算，真实的复用率是三成八。差出来的七个点，是服务端虽然一行不改，却还得为第二个端新增一批接口。
问题二：服务端是现成的，为什么还要新增接口
因为小程序端有一大堆能力是平台白送的，到了 App 里全部要自己搭。
登录是第一处。小程序调一次 wx.login 就静默拿到 openid，App 没有这个东西，得老老实实做手机号加验证码。短信通道按条计费，市面价在每条三分五厘到四分五厘之间，六家店合起来一个月大约四千两百条，摊下来一百五十元左右。钱不多，麻烦在账号合并：存量三千八百个会员全是从微信进来的，新会员从 App 进来只有手机号，同一个人必须只有一份课时余额，所以要建一张账号映射表，还要把历史数据回溯一遍。
推送是第二处。教练的接单提醒原来走小程序订阅消息，一次授权只能推一条，本来就不好用；到了 App 要改成系统推送，安卓这边还得按厂商分别接一遍。支付是第三处，微信支付的 App 支付要单独申请一个应用，商户号可以共用，但 appid 不同，退款回调地址得再配一套，对账时两个 appid 的账要分开拉再合。
这些加起来是十二个接口、九个人天，账号合并连数据回溯另算五个人天。所以小程序定制开发做完之后，服务端并不是白捡的，是打了折的。
问题三：那用跨端框架一套代码打两端，不就没有二次开发了
私教课时这类系统的界面可以分成三种，跨端框架对三种的态度完全不同。
第一种是表单和列表，购课下单、课时明细、会员资料、体测记录，这些用跨端方案复用率能到八成五以上，要改的基本只是样式和刘海屏安全区。
第二种是手势密集的交互，最典型的是教练端那张周视图排课表，七天乘十四个时段等于九十八个格子，长按建课、拖拽改时间、跨天复制课程。在红米和畅享这类四千元以下的四 G 机型上实测，一次重排要四百毫秒以上，帧率掉到三十以下，教练当场就会说卡。这种要么写原生，要么改成虚拟滚动加局部重绘，两条路都得单独排工时。
第三种是碰硬件的，前台平板扫码核销、蓝牙手环读心率、闸机开门。跨端框架在这里只能当个壳，功能全部靠原生插件顶着。
算总账：双端各写一遍原生是四十二个人天，跨端方案二十六个人天，省了百分之三十八。但跨端不是消灭了二次开发，是把二次开发从整个前端重写压缩到两三成的原生插桩，而且每年系统大版本升级还要额外两到三个人天做兼容回归。
问题四：既然迟早要多端，当初哪一步做错了
三笔历史欠账都落在当初那轮小程序定制开发里，一笔比一笔贵。
最贵的是课时扣减写在了前端。教练点“确认上课”，是小程序里先算余额、再提交结果，服务端只负责落库。App 端要重写一遍同样的算法，两边只要有一点差异，就会出现小程序显示剩八节、App 显示剩九节。正确的做法是扣课时必须是服务端一个原子事务，余额校验、扣减、写流水、提成计提四步放在同一个事务里，前端只传会员和课程两个 ID。这一处返工六个人天。
第二笔是文件路径。教练上传的体测照片当初直接用了小程序的临时文件机制，没走统一的存储路径规范，App 端读不到旧照片，得写一段迁移脚本把两年的照片重新归档。
第三笔是权限模型按页面配的。五个角色，店长、前台、私教、主管、财务，权限表里存的是能不能进这个页面。App 的页面结构跟小程序不一样，整张表作废，得改成按操作点配，七十三个操作点重新对一遍角色，四个人天。
问题五：现在补，比当初做对贵多少
拿扣课时这一处算最清楚。当初把逻辑放到服务端，多花一天半；现在返工六个人天，加上双端数据校对两个人天，再加上那三周里冒出来的十四笔课时争议——每笔人工核账二十分钟左右，还得给会员各赔一节课。倍数大约在五倍。业内常说改一处贵十倍，这个案子没到十倍，但五倍是实打实的。
换成预算口径更直观：在小程序定制开发的首期里做多端预留，成本大约占首期的百分之八到百分之十二，首期八万的话是多花六千四到九千六。事后补是三万五到五万，还要搭上一段两端数据不一致、客服天天手工核账的时间。
问题六：那是不是所有项目一开始都该预留多端
不是。看三个信号，中了两个以上再花这笔钱。
一是有没有非微信生态的硬入口，闸机、平板前台、蓝牙设备、门店大屏，占一个就算中。二是单店月活会员是不是超过八百，低于这个数，App 的装机量撑不起后续的版本更新和推送成本。三是有没有员工端的高频重操作，教练每天提交二十次以上表单属于这一类，员工愿意为效率装 App，会员通常不愿意。
只有会员端约课、单店月活三百以内的健身房，预留就是白花钱。那百分之八的预算花在课时对账口径和退课规则上，收益比预留多端高得多——课时纠纷带来的退款和口碑损失，比晚半年做 App 的损失大得多。
问题七：预留就是把接口拆干净，这样够不够
不够。接口拆干净只解决了调用形式，真正决定第二个端便宜还是贵的是另外三件事。
一件是所有写操作的业务计算必须在服务端，前端一行都不许算。课时扣减、提成计提、课包有效期顺延，这三样都是写操作，前端只能显示服务端返回的结果。
一件是权限表的主体必须是操作码，不是页面路径。七十三个操作点各给一个码，端上只问一句这个码我有没有，端的形态换成 App、平板还是网页都不影响这张表。
还有一件是接口契约里的字段命名不带端的前缀。不要出现 wx_avatar 这种字段，就叫 avatar_url，否则第二个端接进来光是字段翻译就是好几天的活，而且翻译层一旦留下，第三个端还得再翻一遍。
这家健身房后来做前台平板端，报价单上二次开发那一栏写的是七个人天，比做 App 那次的二十六个人天少了七成多。差别不在平板比 App 简单，而在中间那次返工顺手把上面三件事都补了——补完之后，小程序定制开发留下的那套服务端才真的成了一份能反复用的资产。
