ARTICLE · 1153625
源码拿不回来怎么办?老系统接盘的 5 条实战路径
先说个场景
客户找过来，说有套系统必须维护，但是——
开发的人走了，源码也带走了。
系统还在跑，业务还靠它，可你手里只有一个装好的程序和一堆看不懂的文件夹。
这种情况我在几年里遇到过不止一次。第一次遇到的时候，我也慌。
后来做得多了，慢慢摸出来：源码拿不回来，不是死局。真正的问题是，你得在五条路里选一条，而不是一眼盯着最贵的那条。
下面一条条说。
第一条：重构
思路：不看老代码，按现在的业务需求重新写一套。
优势是干净。老系统积累的历史包袱，一次清掉；技术栈换成你熟的，后续维护成本低。
代价是你要把业务重新问一遍。老系统的逻辑，很多藏在细节里——客户不会主动告诉你「这个字段超过 500 就报警」，因为在他眼里那是常识。你得一条条挖。
适合：业务链路不复杂、客户能说清规则的场景。比如一个进销存、一个排班表、一个对账工具。
不适合：客户自己都说不清的系统。你重构出来的东西跟他记忆里的对不上，责任全在你。
第二条：逆向
思路：把编译好的程序当黑盒，用工具还原它的逻辑。
先看轮廓——这个程序调用了哪些系统接口，对外暴露了哪些函数。再看逻辑——把核心模块反编译成勉强能读的代码，顺着调用关系把业务串起来。
优势是精准。你能拿到原始的行为，包括那些客户自己都忘了的规则。
代价是慢。一个中等复杂度的系统，摸清轮廓可能几天，理清逻辑可能几周。而且这活需要专门的积累，不是每个程序员都熟。
适合：业务复杂、规则说不清、但又不能出错的老系统。
不适合：赶时间的单子。逆向来不了快的。
第三条：替换
思路：不修了，换掉。买现成的软件，或者换成一体的云服务。
优势是快，而且以后不用你养。对客户来说，月费往往比一次性维护费更容易接受。
代价在两个地方。一是数据迁移，老系统里那些年月攒下来的数据，格式往往是历史遗留的，清洗起来很费劲；二是人的习惯，用了十来年的界面突然换掉，员工的抵触情绪比你想象的大。
适合：业务标准化程度高的场景，比如通用的财务、进销存、简单的门店管理。
不适合：业务有大量定制规则的系统。标准产品装不下那些特殊逻辑。
第四条：并行
思路：老系统继续跑，新的在旁边建，数据两边同步，新系统稳了再逐步切流量。
优势是最稳。任何一步出问题，都能退回去。客户最怕的「切换当天出事故」，这条路基本能避免。
代价是周期长，而且中间有一段时间你要同时维护两套。工程量是明摆着的。
适合：绝对不能停机的核心系统。比如门店在营业、医院在挂号、工厂在生产。
不适合：客户预算紧、又急着见效的。并行是拿时间和钱换稳。
第五条：谈判
思路：去找源码。找原作者谈，找当年那家外包公司谈，或者翻合同看知识产权归谁。
这条最容易被忽略，但有时候代价最小。我见过客户花两天翻出一份十年前的外包合同，里面明确写了源码归属，最后用很小的成本把源码拿回来了。
优势是釜底抽薪。拿到源码，前面四条路的成本全都降下来。
代价是不确定。人可能联系不上，公司可能注销了，合同可能没写清楚。而且谈的过程，有时候比技术活还耗心力。
适合：任何情况都值得先试一下。花两天问一问，比闷头干两周划算。
怎么选？一张决策顺序
别一上来就选最贵的那条。我一般的判断顺序是这样：
第一步，先试第五条。花两天时间翻合同、找联系人。能不能拿到源码，直接决定后面怎么走。
第二步，看系统能不能停。不能停的，优先考虑第四条并行，或者第二条逆向。
第三步，看业务能不能说清。客户能说明白的，第一条重构往往性价比最高；说不明白的，就得靠第二条逆向把逻辑挖出来。
第四步，看业务标准化程度。越是通用业务，第三条替换越划算。
这四步走完，路径基本就定了。
一个真实的例子
我自己遇到过一套老系统。原作者离职，源码被带走，客户手里只有一个装好的程序和几个动态库文件。
那次我们走的是逆向这条路。
先看程序依赖了哪些模块，确认它分成几块：读文件的、内存计算的、网络同步的，还有一个插件扩展。轮廓出来之后，再一个一个模块还原逻辑。
最难的不是技术，是耐心。很多函数名早就没了，剩下的都是编号，只能靠输入输出反推断它在干什么。
那套系统最后是重建出来的，跑得比原来还稳。
但说实话，如果当初能拿到源码，这件事的工期至少能砍一半。
所以我现在接这类单子，第一件事永远是问：真的拿不回来了吗？
结语
源码丢了不可怕，可怕的是明明有五条路，却只盯着最贵的那条走。
先谈判，再判断停机要求，再看业务清晰度，最后看标准化程度——顺序对了，成本和风险都会低很多。
技术能解决很多问题，但选对路径，比技术本身更值钱。
往期相关：
《国庆前，我帮客户救活了一把 Delphi 6 老系统》 《数据库巡检怎么接单？我总结了一套从救火到长期合作的路径》
关注我，下期接着讲老系统里的一个技术细节：VMT 函数指针表，以及为什么它能帮我们还原一套老系统的面向对象结构。