重构项目的解题思路-技术圈

悟出道者自然成道。
我舅舅

前言

做项目有三种方式，新项目、维护项目和重构项目。

如果程序员可以选择，在新项目和重构项目之间，大部分技术人员会选择新项目这条路，因为没有历史包袱。

新项目是从零到一，完完全全的新项目，没有任何历史包袱，技术人员可以“自由”地发挥，但对于老板或企业则是高成本、高风险；维护项目是一个平稳且长期的过程，这过程会循序渐进、不断迭代，要求每一次版本的更新和发布都要平稳，既要上线新功能又不能影响现有主流程；最后，重构项目是又一个历史转折点，意味着要在沉重的历史包袱下，把之前的项目推倒重来。

这一次，我们将一起来探讨重构项目，因为它是企业成长的必经之路。项目重构得好，企业会发展更顺畅、更迅猛；项目重构困难或失败，不仅成本高昂，还会阻碍企业向前发展，甚至破坏已有的正常运营活动。

更严峻的是，在实际中，重构项目的情况会更为恶劣。

下面结合真实案例，分析重构项目有哪些经典的特征，再来寻找更好的解决方案和处理方式。

代码重构、系统重构和项目重构的区别

首先，为避免混淆，我们先来区分下代码重构、系统重构和项目重构。

代码重构，是针对源代码的重构，具体到一行代码、某个函数、某个代码文件、某个模块，可以应用由Martin Fowler编写的《重构,改善既有代码的设计》里面的技巧和做法。代码重构和具体的编程语言有关，一般是由技术人员本人自发，需要花费的时间非常短，几十分钟或几个小时不等，并且由个人就能完成的事情。重构后，不会改变现有的功能，目的是了让代码风格更统一、更容易理解。

系统重构，是发生在同一个系统内，属于更大范围的代码重构，涉及单个系统内的多个模块或者核心流程改造。主要为了降低系统的维护成本、减少冗余重复代码、提升开发效率和满足自动化单元测试的条件。

项目重构，是更高层次、更高维度的重构，通常由高层管理者、企业负责人发起而非一线的技术人员，涉及的层面、需要考量因素会更为复杂。

如果说代码重构是一条线，系统重构是一个面，那么项目重构就是立方体的，还是不透明、不规则的庞大立方体。至于这个立方体能不能在指定的时间，按我们规划的路线到达目的地，以及如何到达，就是本章要讨论的重点。

项目重构案例

我们先来看两个项目重构的案例。

某美容企业的S2S2B2C重构项目

某家美容企业，在过去十年一直经营细分领域的皮肤美容业务，利用自主发明的专利和权威专家的研究，结合贴心的服务，其单店模式得到了客户的认可和积累。出于企业发展的需要，该美容企业在战略上，想从单店模式调整为多门店加盟的模式。很明显，以往近十年研发的单店HIS系统是难以满足新商业模式的需求，需要进行项目重构，打造全新的S2S2B2C新业态的系统架构。

所面临的挑战主要有三方面：首先，以往为了加快研发速度而采用了第三方低代码开发平台，但逐渐暴露了性能和用户体验问题，并且对于复杂的需求难以化繁为简；其次，技术人力有限，只有3名技术人员1名运维1名测试，难以在开展重构项目的同时维护现有的业务，并且作为传统行业过多技术人员将会极大增加企业的研发成本；最后，S2S2B2C新业态的系统架构在技术架构、项目管理和产品需求等多方面都提出了新的挑战。

当时，在该公司的大会议室，和该企业的产品总监兼创始人、技术经理和技术团队一起，经过当面沟通一天后，从上午到中午到下午。回来后，用了几天的时间，我给这家整理项目重构的解决方案，在项目计划甘特图中初步评估是需要历经4个月的时间。

并且根据该企业现有的团队人员，和新采用的技术栈，初步评估需要共13人的研发团队。

项目重构的典型特征

项目重构，不仅有历史包袱，还有新的挑战，同时面临各种不确定的因素，处处有风险。对于技术团队而言，要在新系统研发和旧项目维护的双线并行开展的压力下来回切换；对于企业而言，如果需要用重构后的项目去验证新的商业模式，则要承担极高的试错成本。

概括来讲，项目重构有以下典型特征：

需要在保障现有业务的正常运营下进行新系统的研发，并且核心是旧系统的保障和维护，其次才是新系统的研发，因为旧系统是企业现金流和收入的主要来源
需要对原有的技术进行革新，采用更新的技术框架、更复杂的解决方案、更专业的工具
需要对人员进行必要的调整和补充，甚至需要补充不同岗位的技术人才
系统研发完成后，需要进行历史数据的迁移，这是一件工作量非常庞大的工程，复杂、耗时、并且必须100%无差错无遗漏无重复
系统上线前，需要对现有的用户进行培训，特别包括内部员工、合作伙伴、上下游供应商、顾客
需要准备周密的版本切换计划，以及回滚计划和预案

项目重构的挑战与痛点

对应上述提到的典型特征，不难发现和总结项目重构的挑战与痛点。

新系统与旧项目需要双线并线开展，时间冲突、团队压力大，并且这个过程持续越久，越痛苦，后期切换越难
补充人员可以解决和缩短当前短期内的研发周期，但会导致长期的研发用人成本提升，可以培训已有人员转型或采用外包驻场协同开发
历史数据迁移成本和时间都很高，往往会容易被上层领导低估

明确重构项目的商业价值

一个商业模式的想法，在大脑中或者在沟通交流中，可以随时变更、完善和调整；一份需求文档，在未进入研发阶段之前，修改和更新它的成本也相对很低；但如果经过需求评审后，项目已经通过项目排期、进入研发阶段、开始集成测试、甚至准备交付上线切换时，这时再来变更底层的商业模式以及项目的定位和方向，其变更成本就会非常高昂，不是一般的高。

项目，是由一个或多个系统构成并支撑公司业务流程的正常运转。在这些系统的背后，是成千上万行经过开发、调试、测试和集成的代码、变量、函数、类，以及与之息息相关的数据库表、字段、索引和数据，还有界面、交互、环境、服务器、网络等。试想一下，如果到后期再来变更企业的商业模式或盈利模式或业务模式，前面的很多工作都可能会前功尽弃。

在决定开始项目重构之前，作为企业决策高层，非常有必要对接下来的项目重构的商业价值、意义、成本预算、风险、决心进行评估和定夺。

只有明确了企业想要达到的效果，以及可量化的目标和战略规划，才能给项目重构提供定心丸，才能给整个漫长而艰巨的重构过程提供有力的保障。