LEGACY / REBUILD / INTEGRATION

旧系统的问题，
不一定需要用“重做”解决。

先读取现状、依赖和数据，再决定修、接、换还是逐步重构。目标是降低风险，而不是制造另一个新坑。

01SCENE / 04

legacy-system.tsREFACTOR MODE

01 inspect(existingSystem)
02 map(dependencies)
03 protect(data)
04 keep(whatWorks)
05 replace(blockers)
06 connect(newServices)
07 ship.incrementally()

READ

第一步不是改，
是读懂。

代码结构、依赖版本、数据库、部署、第三方接口和真实故障必须先摸清。没有上下文的“直接改”风险最大。

代码审阅依赖梳理数据库与部署

MAP

把风险
按优先级摊开。

区分会造成数据/业务事故的问题、长期技术债和纯体验问题，决定先解决哪一层。

风险地图问题清单改造边界

CHANGE

能增量改，
就不一次性推翻。

优先让系统持续可用：一块一块替换、增加兼容层、拆出新模块，再逐步减少旧逻辑。

增量开发接口兼容模块重构

HANDOVER

改完之后，
还要有人能接。

补齐环境、部署、关键模块、接口和常见问题文档，让系统不再依赖“只有原作者知道”。

测试回归部署文档长期维护

DELIVERABLES

漂亮只是第一层。
最终必须能上线、能维护、能继续改。

01需求 / 结构 / 原型

02视觉 / 交互 / 响应式

03开发 / 联调 / 测试

04部署 / 文档 / 交接

HAVE A PROJECT?

把你的需求丢过来↗

旧系统的问题，不一定需要用“重做”解决。

第一步不是改，是读懂。

把风险按优先级摊开。

能增量改，就不一次性推翻。