上周收到一位老客户的求助：三年前做的小程序开发项目，现在想加个直播功能，原来的开发商报价时说代码基础太旧，加了会出问题，问我是不是只能推倒重来。我们花两天做了次评估，结论是救得活，这个过程值得写出来。
先做代码体检再谈方案
评估看四样东西。一看代码结构：模块划分清不清楚，有没有文档；二看技术栈新旧：用的框架版本微信还在不在维护，接口规范过没过时；三看数据库设计：表结构能不能撑住新功能；四看历史改动：这几年是找谁改的，改动乱不乱。这家的情况是：后端代码还算规整，前端页面是老写法，数据库设计有远见，当年预留了扩展字段。体检下来，后端和数据库保留，前端重写，预估费用比全新开发省四成。小程序开发的技术债是有价格的，评估就是把它标出价签，让决策有依据。
哪些部分值得留，哪些别留
- 数据库和业务逻辑层：规则沉淀了几年，能留尽量留
- 后台管理系统：界面旧但功能在，可以局部翻新
- 前端页面：老写法改造成本高于重写，果断换
- 没人看得懂的模块：连原开发商都说不清的代码，留着就是雷，重写
判断的核心不是代码新旧，是改造成本和新写成本的对比，逐模块算账，不是一刀切。评估报告要落到纸上，每个模块的处置和理由写清楚，改到一半翻脸扯皮的项目，多半是当初评估没留痕。
重构期间生意不能停
老系统还在线上服务客户，重构不能停机。通行做法是新旧并行：新版本在独立环境开发，核心流程用真实数据灰度测试，确认稳定后切流量，老版本保留两周作后备。这家客户选在业务淡季启动，前后六周，用户几乎无感切换。期间只有一次小事故：新版本的优惠券规则和老版本差了一档，靠灰度期的数据比对提前发现，没伤到真实用户。灰度期宁可多留一周，数据和口碑上省不得。
重做还是重构的判断标准
给个简单尺度：业务规则没大变、代码有文档、原团队能对接，优先重构；业务模式已经转向、代码全无文档、原开发商失联，重做反而干净。那个「代码太旧加不了功能」的报价，有时是实话，有时是想要新单的话术，评估一遍就有数。拿不准的项目，先花小钱做评估，比拍脑袋省大钱。手上有三年以上的老系统，拿不准怎么处理的，可以把源码情况发给比格网络做个体检，留多少、换多少、花多少钱，先有个底再拍板，别被一句话带着走。
