by zhimaxingzhe from 如何接手他人的零碎-遗留零碎重建之道法术器势志 欢送分享链接，转载请注明出处，尊重版权，若急用请分割受权。 https://zhimaxingzhe.github.io

前言

成熟的公司会有大量的存量零碎，程序员不免接手别人开的的零碎。万一不小心接手的零碎过于腐烂，祖传代码难以破译，一边吃力不讨好艰巨保护老零碎，一边在下面做新业务，出了问题要背大锅，一头包，难有好问题，满身疲乏，终成大冤种。本文尝试探讨如何接手遗留零碎的方法论，重建遗留零碎的道法术器势志，使得遗留零碎跟上组织内零碎演进和满足业务需要，逐渐从泥沼中走脱。

什么是遗留零碎？接手他人开发的零碎，能够是各种起因导致的零碎建设、保护工作的交接，对于接手人来说就属于是遗留零碎；严格意义上来说任何已存在的零碎都能够是遗留零碎。

接手一个遗留的零碎并非肯定要重建它，如果是一个行将辞别历史舞台的零碎，咱们没有必要探讨，只须要把它“送好最初一程”即可。本文探讨的领域是遗留零碎将要长期退役上来，并且会在下面倒退更多业务，长出新性能的零碎，也就是图中将遗留零碎变成一个现代化的零碎。

那么首先，在拿到交接的资料中根本理解零碎后，咱们从业务需要、零碎性能、零碎框架，特地是对系统设计有了整体的意识之后，咱们就应该思考一个问题，该零碎是否合乎古代零碎的要求，技术上应该连续现有设计，还是重构、重写、重搭、迁徙。如果是连续现有零碎设计，则本文往下就没有必要再往下看了。

当你认为该零碎切实是烂，交到你手里保护你就要做大冤种了，这个时候就应该思考重建该零碎的办法（套路）了，最好能做到私人订制。如何能做到私人订制？咱们从业界成熟方法论说起，再以笔者教训实战状况，总结梳理出能抡的三板斧。心愿能帮忙到各位，若有帮忙，请一键三连。

以术载道，以道驭术，以法固道，长于驭器，勤于练术，术器生势，趁势成志。本文的内容较多，先来一览目录，源道法术器势志都蕴含哪些内容，随后再具体开展陈说。

一、源起-为什么要重建

首先要明确重构的动机，把动机详分明，痛点在哪，拿进去和组内的同学一起探讨，切记要主观。是零碎框架太老旧？还是零碎架构难以为继？还是有很多坏代码的滋味？还是因为零碎太过简单，没方法短时间内理解到全，出于处于懈怠，抉择回避？还是遗留零碎太过腐烂，历经N手开发人员后，基本没有人员、文档、任何资料能撑持起你去意识该零碎，导致你无奈从旧零碎中取得常识，所以想要尽快与遗留零碎划清界限？

01、遗留危险


1.业务不能满足倒退
从业务角度来说零碎的能力无奈反对业务倒退的须要，功能设计落后于业务倒退，须要革新现有性能的能力。

2.零碎能力不能满足倒退
如零碎部署架构不能满足业务规模的倒退，无奈撑持用户量、访问量。

3.新需要交付工夫长
在不理解的零碎上做需要会遇上或多或少的未知状况，须要在一直踏坑、填坑中调整，实现工作的工夫须要一直加长，交付工夫经常比预估的要长。

4.缺点多，到处救火
团队长期处于救火状态，每天白天做消防员，早晨做施工员。不论是业务团队还是技术团队都处于较大压力的工作环境中，长期以往精神状态会受到影响，不利于团队建设。

5.交付周期不可控，业务无奈按期发展
因为第3、第4点导致交付工作的投入有余，须要缩短排期打算，无奈及时上线新需要，新业务也无奈按计划发展。

02、研发价值

1.研发老本高居不下

这个不言而喻，不须要解释了吧。

2.架构落后古老

如利用是单体的，须要集群化、微服务化、分布式化。

3.模块设计不合理

模块间边界不清晰，开发人员不能很好辨认模块分层，不能正确安顿类的寄存门路，导致模块边界越来越不清晰，远来到闭准则。如采纳MVC架构，没有严格依照MVC模块划分准则，controller 调用 dao的状况；采纳DDD架构，domain之间有相互调用的状况等。

4.模式设计凌乱

模式设计乱用，没能联合业务来正确应用设计模式，导致接口拓展矛盾重重。

5.代码腐烂

代码年久失修，堆积成山。

6.新增、批改代码艰难

N代的祖传代码，每个开发人员都依照本人的用意增加代码，远离繁多职责，接手人想要增加一个简略批改，却须要同时思考N多种状况。

7.没有足够的测试

遗留代码没有写测试用例，没有用例代码，代码不可测试，或者没有足够的测试用例验证已有性能的正确性。

8.没有足够的常识（人/文档）

团队中找不到对系统足够理解的人，可能此前的开发团队成员全都来到了，或者只有多数不理解全局状况的人员留下来了，或者组织架构调整，零碎没有追随人员变动调整，全都交给了新的团队来负责。没有跟上零碎现状的文档，没有能够理解零碎现状状况的文档，甚至没有文档。

9.难以定制让人释怀的交付打算

对于不理解的零碎，始终会有坑在前头，打算赶不上变动，何况这些坑就不是打算的一部分。

10.界定批改带来的影响

A: 一处小批改，把零碎搞垮了？批改前怎么不评估影响？

B: 我不晓得这点批改会影响到另一个模块，没有文档没有正文，我甚至不晓得那个外围模块有依赖这里。

A: 没做集成测试？

B: 只改了这点，单测没问题，在这个模块范畴下也是没有任何问题的，所以没有做全局的测试。

A: ......

11.难以管制交付危险

既然不晓得影响，那就更不晓得交付进来的产物是不是牢靠的，如果经常出现问题，会打击团队士气，开发人员信念会丢失，兴许终日都在放心线上跑的代码会出问题，变成祷告式开发，神学运维，玄学经营。

03、业务价值

让业务可能衰弱倒退，或者能够从新设计零碎性能。不被技术债连累，不被古老技术限度倒退，无效牢靠的交付周期，更牢靠更现代化的业务能力，用户体验更好。

04、重建危险

重构若不做好危险管制会带来难以管制的危险的状况下。须要列出危险TODOLIST，盯紧危险因素在重构过程中的解决状况。

还有一种非凡的危险是重写后的代码与原来的十分类似，因为要思考简单的需要场景，为了防止这一问题，就要从旧零碎吸取到足够的常识，来判断该性能的实现是否河里了。这里除了从浏览代码、查找文档之外，最好的形式是从构建测试开始，依据测试来理解性能\接口的行为。

1.工作量超预期

重建自身是简单的工作，须要依据零碎就地取材设计方案，遇到意料之外的状况也是常态，工作量超出预期就不言而喻了。

2.卡住业务倒退

无奈按期交付，以后重构带来的变动使得零碎版本没方法交付业务需要。因为不能在重构的版本上做业务需要的开发，如果在重构前的版本上开发业务需要，又会导致业务代码在交付后还要合并到重构版本上，带来联调、测试、验收、验证等工作量；如此一来，团队取舍艰难，从而可能卡住业务倒退。

3.逐渐变成老零碎的样子

有的时候看到整个模块十分复杂，容纳了十分多的状况，逻辑点十分多，接口代码简短不堪，开始着手重构，但越重构越发现新的实现越来越靠近老零碎的实现，因为要实现的业务场景自身就是很简单的。

4.切换后回退艰难

重建带来的批改，在研发的各个阶段都可能导致回退，一些较高层面的重构回退的老本也会升高，导致回退难度大。如将零碎架构从新布局，本来处于特定业务畛域的服务该当积淀为根底服务，在公布后发现实际效果带来更多问题，还不如原来的形式解决来的简略；又如将模块从新划分，将局部接口实现迁徙到更内聚的模块中，之后又做了接口代码的批改，增加了许多类，在对理论状况更加理解后，认为这些接口归属在原来的模块下是更加正确的；此时想要回退就会比拟麻烦。如批改了代码的目录构造后，又批改了接口代码，此时想要保留接口代码的批改，还原代码目录构造就不能通过退回来实现。

还有更麻烦的奖数据库重建后，新库在线上运行遇到较多问题，此时如果没有做好退回的方案设计，将会陷入两难地步。

05、重建老本

软件开发总成本 = 开发成本 + 保护老本；软件维护老本 = 了解老本 + 批改老本 + 测试老本 + 部署老本。若是没有梳理重构老本，会导致工作总是超出预期工夫。

包含以下方面的工作量：

1.梳理工作量

2.设计工作量

3.开发工作量

4.测试工作量

5.切换工作量

06、重建收益

1.升高研发老本

2.零碎架构现代化

3.模块设计更迷信

4.模式设计更迷信

5.代码新生

6.短缺的测试用例

7.贴合实现的文档

8.进步交付效率和品质

9、可测试性，TDD形式

如果是重写的形式来重建，还有以下益处：

1.不受原来包袱的限度

2.编程标准的转变

二、道-怎么重建

01、零碎的申明周期和倒退法则

零碎自身会产生交替更迭，新零碎会代替老零碎，

当然在任何阶段都有可能产生交接，对于新接手的共事来说都是遗留零碎。

02、研发流程周期

麻利开发时代下，咱们须要经验需要、打算、编码、构建、单元测试、功能测试、零碎测试、公布、运维、监控等阶段，有可能一个团队下在并行几个devops环，尽管不提倡，然而这是很多程序员正在经验的事实。

在联合零碎申明周期和研发流程周期来看，咱们须要怎么样的重建流程呢？

03、重建流程


PDCA是因为爱德华兹·戴明博士而出名的，很多人认为戴明博士是古代产品品质管制的始祖，别离指布局、执行、查看、口头/修改、总结。

我在前后加了评估、总结，评估是为了确认是否有重构的必要，评估复杂度、影响范畴以及工作量得出重构老本，从重构收益和危险。

04、重建计划抉择

因材施教、就地取材，隔靴搔痒，视零碎状况而抉择不同层面的重建计划。

重构

将现有零碎在不扭转软件的内部行为的根底上，扭转软件外部的构造,使其更加易于浏览、易于保护和易于变更。

重写

重头开始写一个全新的零碎来代替现有零碎。

重搭

重搭也属于重写的一种，只不过偏差于因为零碎架构不合理导致的重搭重建，外部业务性能的实现并不需要大改，大部分是迁徙和整合。

迁徙

当遗留零碎是能够合并到一个现代化的零碎当中时采取的计划，通常和重搭的后半局部工作是统一的，外部业务性能的实现并不需要大改，大部分是迁徙和整合。

最佳实际形式：持续性重建

以上形容的每一种办法在机会执行时都会被“同时要反对业务倒退”打脸，咱们简直做不到残缺地执行重构、重写、重搭、迁徙的同时丝毫不耽搁业务的倒退，不产生线上问题，为了防止这些大动作导致系统陷入不可用、缺点过多等难堪地步，咱们不能把步子迈得太大，这样才不会扯到这个腐烂的蛋，再呈现问题时至多还有疾速回到上一步的可能。当然你可能会想，回滚零碎公布不就好了么？然而，回滚工作量和零碎现代化步长是成正比的，零碎陷入泥潭的概率会减少，步长越大零碎危险也就越大。

既然如此，咱们只能是增量重建，在每个重建阶段都应该提供业务价值，跟上业务倒退，应该能够在任何重建阶段之后都能取得一些重建带来的益处。

所以咱们看到 Java 界最会总结的程序员 Martin Fowler 举荐的绞杀模式是一种最佳实际。

绞杀者模式


此处不赘述绞杀模式，可查看原文。

https://martinfowler.com/blik...

https://martinfowler.com/blik...

三、法-重建方案设计和流程


定制重构的指标，划定重构的范畴，评估影响，与团队达成共识。

1.达成团队共识

所有以业务为先，联合业务发展状况，适时联合起来布局重建工作。

2.取得组织的批准

与组织上下游做好足够的沟通，保障大家对遗留零碎重建达成统一共识，组织应明确重建的预期，重建过程中遇到危险应尽早裸露危险，也更容易取得组织的了解和反对。

3.抉择重构指标

寻找容易实现的指标（低危险、低难度）+ 痛点（价值高）来布局重构，以此发展的重构更能取得成就。

重构的惟一目标就是让咱们开发更快，用更少的工作量发明更大的价值。—— 《重构：改善既有代码的设计》

4.鼓起勇气，不要胆怯变动

当你试图对工作形式进行这些改良时，政治奋斗可能抬起它俊俏的头——《拥抱改革：从优良走向卓越的 48 个组织转型模式》

惟一不变的是变动，拥抱变动，成为变动的一份子。

决定我的项目范畴

我的项目指标

通常重构都随同着业务需要一起发展，兽性本是无利不起早，业务需要和重构范畴能正好重叠是最好的状况，但通常两者能有交加就挺不错的了，甚至这两个毫无交加，这种状况下咱们更加要讲重构痛点，明确为什么要重构，怎么重构，重构后是怎么样的，能给团队、业务带来什么益处，单方沟通出一个指标清单。

记录我的项目范畴

  • 新性能
    本次重构会带来哪些新性能，哪些是新增的业务需要。
  • 现有性能
    与本次重构范畴相干的现有性能是哪一些，剖析重构将会对这些性能造成影响，须要重点测试和验收。剖析自身会对重构范畴进行扫视，如不能管制重构带来的危险，须要从新回到为什么要重构这部分内容当中去，是否重构的计划自身是不合理的，是否应该放弃重构，或者抉择重写、重搭、迁徙等其余计划。
  • 及时性与性能完整性
    打算要在何时实现公布，里程碑的危险是哪一些？如果我的项目要害门路无奈及时实现，是否在不影响性能完整性的状况下，具备调整性能实现范畴的条件？
  • 是否能够拆分为更小的阶段
    小步快跑是很好的工作形式，以后的我的项目范畴是否能够拆分为更小的阶段来实现，小步重构，疾速交付公布，这样如果遇到不可预感的危险时，能够有疾速回退的方法来防止更大的问题。

从构建测试开始

重构是对已有的零碎、性能、代码进行批改，保障现有零碎性能能够失常运行是团队承受重构的前提，那么保证质量的方法就是测试。所以在《重构：改善现有代码的设计》中，在很多探讨重构的书籍、文章中，都有提到构建测试是重构的开始。具备齐备的自动化测试能力，最好有良好的继续集成系统，在每次小步重构提交后，能够疾速得悉重构对系统整体影响的反馈。
这里也有一点须要阐明是，最小可公布单元（模块）应该足够小，一个模块承当太多的性能，会导致自动化测试等评估重构的指标难以疾速产出，拖慢重构的效率。能够想到如果只是批改了一个字段名，却要跑十几分钟的自动化测试能力晓得重构的后果，那将会打击重构的积极性，程序员将难以放弃对重构的急躁，无奈将重构融入日常工作当中。

软件质量保证是重构之所以能被组织承受的基本，如Google 测试之道认为软件品质是先天就创立进去的，Jsones Capers 的测试左移认为在编码阶段发现缺点的修复老本是最低的，咱们应该在编码阶段做足够的测试，这样可能晋升研效保证质量。

测试遗留代码

为遗留代码创立测试用例，笼罩遗留代码的测试，构建业务护城河。

测试不可测试的代码

在开始重构前，须要先有单元测试，有单元测试，就能够开始重构，找到突破口，逐渐建设更多的测试，进而能够做更多的重构和重建工作。
更多应用mock、结构哑实现来防止测试过程中遇到的副作用。
常见的测试策略有

  • 框架/模式库测试。xUnit，xMock，如 Java 语言里的 JUnit, Mockito；JavaScript 中的 Jest
  • 端到端 API 测试。JMeter，Postman，Rest Assured，Karate
  • UI 集成测试。Protractor
    思考到测试即文档，在实现实现的时候，会配合一些反对自然语言形容的框架，如：
  • 文档式测试，Gauge （支流语言），Concordion（Java）
  • BDD 测试，Cucumber（支流语言）
  • ATDD 测试，Robot Framework（Python 语言）
    为了与运行客户端一配合，还须要有底层 API 来管制浏览器、客户端利用：
  • Appium。挪动 APP 和桌面利用，反对支流语言
  • Selenium。Web 浏览器，反对支流语言
  • Puppeteer。Node.js API 操作 Chrome 浏览器
没有单元测试的回归测试

单元测试不是“银弹”， 别适度谋求测试覆盖率，适可而止，否则容易导致开发人员从编写简略的测试开始，而不是命中重要的测试指标。
自动化所有测试，这不仅仅是提效，也是品质的保障，手工的测试误差往往很大，稳定性难以保障，成果也无限测试不可测试的代码。

让用户为你工作

结对编程、代码评审、单元测试、功能测试、集成测试、零碎测试、UI测试、性能测试、负载测试、冒烟测试、模式测试，但仍然无奈蕴含所有用户应用的情景。
渐进式公布新版本，同时监控谬误和回归问题。
收集实在的用户数据，并利用它来使你的测试更高效。
执行新版本的灰度测试。

让所有自动化

自动化根底设置、继续集成自动化、测试自动化等是效率和品质的保障，机器比人稳固，手工总会出错，反复的工作形象、封装进去让机器去做，节约下来的工夫能够做更多有意义的事件。同时，这也使得遗留零碎成为容易接手的零碎，重构后的遗留零碎交接给接班人后不再会轻易变成遗留零碎，这是终结遗留零碎的利器。

不同层面的重构

架构重构

架构重构包含零碎群架构、具体的某个服务架构、公共区域等。

DDD架构下，从业务畛域、性能畛域划分零碎、划分服务，以及由此造成的公共区域。

某个服务下比方MVC，接口层、服务层、dao层，还有一些实体、适配器、DDD的domain层、工具。

创立通用的共享组件导致了一系列问题，比方耦合、协调难度和复杂度减少。复用与低耦合 ，自身存在肯定的互斥关系。

模块重构

模块/组件是软件的部署单元，是整个软件系统在部署过程中能够独立部署的最小实体。 —— 《架构整洁之道》

Bob 大叔在书中提到了三个准则：

  • 复用/公布等同准则（REP）。软件复用的最小粒度等同于其公布的最小粒度。正当、无效的包公布策略。
  • 独特闭包准则（CCP）。咱们应该将那些会同时批改，并且为雷同目标而批改的类放到同一个组件中，而将不会同时批改，并且不会为了雷同目标而批改的那些类放到不同组件中。模块包满足开闭准则。
  • 独特复用准则（CRP）。不要强制一个组件的用户依赖他们不须要的货色。繁多职责准则。

所谓模块化，就是力求将代码分出区域，最大化区域外部的交互、最小化跨区域的交互，把本来散弹式。
联合DDD的思维，咱们把零碎依照业务畛域划分为各个模块，再有一些技术领域的模块和一些提供公共能力的放到公共模块，以及一些跨畛域间的组织（编排）模块。按这些规定，造成上下文边界，避免代码越界建设。

模型重构

架构元模型定义了模型中应用的概念和应用规定。 —— 《架构师修炼之道》

聚合行为
如果咱们不创立模式，而间接开始编写代码，那么咱们会播种一堆上帝类。然而，反过来，当咱们有一堆上帝类的时候，那么咱们就须要从类中把行为都抽取进去。

当咱们的贫血模型，领有了行为，就能够进一步形成富血模型，合乎面向对象（OO）的思维。进一步的，咱们能够从业务的角度来思考这个问题，将充血模型改为畛域模型。

类、状态、办法、bean、model等。
基于对于DDD的了解，在零碎中要遵循严格的DO、DTO、VO、BO、DAO、Entity、POJO模型划分。

模式重构

应用设计模式重构遗留零碎代码实现，罕用的有设计模式，工厂模式、单例模式、策略模式、门面模式、装璜者模式、责任链模式、建造者模式等。

代码重构

函数不该有 100 行那么长，20 行封顶最佳。--《代码整洁之道》

联合Robert C Martin的观点，函数长度应该在4-20行之间了，对于简单业务代码来说很难做到，否则就须要将步骤拆得很细，将调用链路设计得很长，这对于代码可读性来说也是个挑战。联合工程实践经验来看，咱们通常会在紧迫的工夫内实现指定工作，按时交付，所以我集体的要求是不超过80行。

大神们的倡议是咱们的方向指引，就好比马丁·福勒（Martin Fowler）在《重构》中的提到一个好的变量名、函数名应该要好到不须要任何正文，读者能明确代码的用处，就像是在浏览小说一样清晰地浏览代码。

我的集体教训来看，工程实际状况下，咱们的我的项目、零碎通常是经手N代的，前人的设计思路、实现过程中的斗争、为适应过后状况增加的解决分支、开发者没有持续遵循最后的设计模式等等简单状况，在经验几任程序员的保护后，业务代码会变得无比简单。特地是外围的业务代码，如果没有足够的正文和文档，没有人敢保障可能在新接手的零碎上疾速理解到足够有用的常识和信息，就敢拍胸脯承诺革新排期。

升高圈复杂度，重构手法参考《重构：改善现有代码的设计（第二版）》，加上古代的IDE都有主动重构能力，所要做的，就是把握重构手法，一直练习，领悟重构手法应该如何施展。

把重构和业务需要离开提交
通常在开发业务需要时闻到怀代码的滋味，脑子里高速评估一圈后认为是时候抹掉这股怪味了。这时候要停下来，决定好是重构后提交代码，还是先开发业务需要提交代码，或者反过来做，这样做的益处是可能利用好版本控制系统疾速回到上一步，且能升高出错率。如果将两者混同在一起，很容易导致大脑须要同时思考这两件事件，容易产生谬误；且在代码评审时、在别人review 这段代码时也能疾速明确批改用意。

四、术-重建中的办法

代码重建办法


把握重构手法，一直练习，领悟重构手法应该如何施展。重构手法的学习参见经典《重构：改善现有代码的设计（第二版）》。

数据库重建办法

蕴含数据库的遗留软件的两种办法：共享现有数据库或者创立新数据库并迁徙数据。

共享现有数据库

革新长久层，适配新数据库数据结构。如果本来长久层设计不合理，或者与服务层耦合较深，则革新起来会比拟麻烦。

创立一个新的数据库

实时同步
业界成熟的工具如canel、maxwell、DataX、Sqoop等。

批量同步
可通过 ETL 工具批量复制，如Kettle、Streamset。

复制流量（双写）
有点是最终决定切换前要做好短缺的验证，切换到新库后无奈回退到上一步。

级联同步
这种计划劣势是简略易施行，在业务上根本没有革新的老本；毛病是在切写的时候须要短暂的进行写入，对于业务来说是有损的，不过如果在业务低峰期来执行切写，能够将对业务的影响降至最低。

五、器-重建的工具


其中继续集成开展来看咱们还会经常应用到如下工具：

甚至是：

六、势与志

以术载道，以道驭术，以法固道，长于驭器，勤于练术，术器生势，趁势成志。

积淀重构资产

重构我的项目公布后，保持复盘总结，能够是集体的也能够是团队的，造成重构的文化；发现流程中存在的问题，以便在下次重构时优化流程，提高效率；积淀出更多好用的工具，每次重构都将反复的工作交给机器，做到自动化，特地是测试自动化工具的改良；积淀出有用的文档，不论是记录还是指南手册，还是性能阐明、设计方案，都须要在还记得分明的时候及时做好整顿。

一些准则和Tips

  • 小步后退，不管改变的大小，一旦变动的文件多了，如移包、重命名用得宽泛的类等等，记得随时提交。
  • 随时可用。如果不能保障随时可用，那就说不上是重构了。
  • 进行编写遗留代码
  • 源代码并不是我的项目的全副
  • 积淀文档
  • 促成沟通
  • 最大化开发团队外部、之间的交换
  • 重建工作是做不完的，继续重构，缩小技术债
  • 定期的代码评审
  • 提前浏览代码、并做笔记
  • 由相熟代码的人疏导评审
  • 写出评审后果，得出口头和事项
  • 自动化所有能够自动化的货色

知易行难，道阻且长，任重道远，整套办法的落地执行还要一直修炼捶打。文中的许要点开展都是一个简单的知识点，若要具体探讨还能够用很多篇文章能力论述分明，限于集体能力和精力，不再具体开展，比方数据库迁徙，比方重构手法，还有测试左移，甚至道法器术势志自身也是浅近的学识。笔者常识无限，认知局限，有有余和纰漏之处，还请各位不吝赐教，欢送在评论交换。若有帮忙，请一键三连。

参考资料：

《遗留零碎重建实战》

《Refactoring: Improving the Design of Existing Code》

《Strangler Pattern》

《Branch By Abstraction》

《零碎重构与迁徙指南》

《高并发零碎设计 40 问》

《Applied Software Measurement : Global Analysis of Productivity and Quality》

《重构：改善现有代码的设计（第二版）》