一边还债一边盖新房，架构升级的“地狱模式“

文章首发公众号【风象南】

一道选择题

以下软件开发类项目哪个最难做

A. 新产品开发
C. 年久失修的老项目维护
D. 产品架构升级同时保持对老版本的兼容

先说A

全新开发，没有技术债，可以根据实际情况进行设计实现，虽然过程可能会有一定的技术难点与时间压力，但整体上能够专注于单一目标，那就是按时上线。

再说C

这种一般属于公司的骨灰级产品，古董级技术栈，文档缺失，代码混乱，食之无味，弃之可惜，维护人员人换了一波又一波，最难的是明知道有很多问题但是你就是不敢动它，通常采用保守治疗，哪里痛医哪里，其中的酸爽只有经历过的人才能体会。

最后看D

产品架构升级一般来说发生在产品还能持续盈利，并且具备不错的市场机会，但是当前产品的技术债已经严重影响迭代开发周期以及需要高昂的开发成本，终于公司决定快刀斩乱麻，重新设计，进行架构升级。

架构升级至少来说顶层设计、使用的技术栈、业务接口、各种中间件大概率会进行革新替换。某种程度上，都可以认为这是一个全新的产品。

但是，这里有个前提，不能丢掉老客户，也就是你做的新版本得能向前兼容，它需要继承C的意志。

想必，到这里，你已经有答案了。

D选项在几个品类中的实现复杂度遥遥领先。

刚好，自己完整组织实施过D类项目从0-1的过程，结果还算不错，分享一点浅浅的经验。

调整心态

首先，做事之前先自我做好自我心理建设，很显然这是一个充满挑战的事情，压力肯定是有的，但是要学会自我调节。拥有一个好的心态是做事的前提，持续拥有一个好的心态是做成事的必要条件。

有人会说，你抗压能力真强，其实，抗压不是关键，学会自我调节才是。

明确目标

明确新版本需要达到的目标，分两类，产品目标与技术目标，后续工作需要紧紧围绕这两个目标进行展开。

产品目标：主要说明新版本除了具备原有版本的能力还会给客户带来什么不一样的价值体验，如要进一步减少客户多少的工作量、提高多少人效、节约多少成本等。

技术目标：主要说明如何从技术层面保证提供给客户的价值可靠且可持续，如性能、稳定性、安全性等方面需要做什么样的提升。

确定边界

首先，确定旧版本的功能哪些需要完整迁移到新版中，同时，新版本要在哪些地方做改进及新增什么样的功能，一定在前期需要控制需求的边界。

如果考虑开发周期和兼容旧版本部分的开发成本，可以不用将所有旧版本的功能进行一比一翻译。

可以对一些低频、边缘的模块通过手动+脚本的方式作为补充方案。

核心一个目的，在有限的条件下，优先保证业务能够闭环。

核心原则

总体原则是以新架构为核心，不能为了兼容旧版本随意的在架构设计或代码实现时进行妥协让步，否则后面可能会出现反噬，旧版本的技术债会进行传染，进而影响新版本。

技术策略

技术策略这里主要分享两个关键点，一个是接口的兼容，一个是数据的迁移。

1、接口兼容

接口兼容出现在旧版本产品已经在客户现场与客户购买的其他类产品或自研产品进行过集成对接，此时新版本的接口改动会直接影响使用。

接口兼容分几种情况

1.1 客户愿意配合跟着新版本进行改造

这种情况处理相对比较简单，提供新版本的接口文档，客户协调各个产品供应商进行修改对接即可。

1.2 客户不想动现有的任何代码

这种情况通常比较普遍，特别是核心业务，一般都会采用比较保守的方案，尽量不动生产环境的任何配置和代码。

此时，技术实现上可通过在新版本中增加兼容旧版本API的接入端点并增加独立的端口，做到访问入口的隔离，方便后续业务及网络策略的控制与统计分析。

通过在旧版本API端点中完成对原有接口及请求、响应的适配。从下图可以看到，业务层整体是复用的。

2、数据迁移

数据迁移一个是工作量的问题一个是机制的问题。

2.1 停机

如果是离线停机迁移，则处理过程比较容易，可以通过如下方式来提高效率

借助ETL工具：利用现有的ETL工具对数据进行抽取、转换和加载，减少人力投入，提高效率。开发配套程序：针对具体业务需求，定制化开发数据处理程序，确保迁移过程中的数据完整性和准确性。

2.2 不停机

如果是生产不能停机，还需要额外考虑不断产生的新数据如何同步到新版本数据库中，何时完成线上切割等。

比如，旧版本增加双写，开发增量扫描复制程序等，关键的关键做好旧版本数据的备份，不可随意删除。

应用场景不同，数据一致性、实时性的要求不同，采取的实施方案也会不同，此处不再详细展开。

总结

D类项目作为技术升级与历史兼容的平衡艺术，堪称软件开发中最复杂的挑战。

它要求团队在架构革新中既要继承旧版基因，又要突破技术债的桎梏，还需确保客户尽可能零成本迁移。典型的既要、又要、还要。

不过，那又如何，做事，咱是专业的。