by zhimaxingzhe from 怎么接手别人的体系-留传体系重建之道神通器势志 欢迎分享链接，尊重版权，未经作者授权，制止转载，授权后转载请注明出处，若急用请联络。 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 推荐的绞杀形式是一种最佳实践。
绞杀者形式
此处不赘述绞杀形式，可查看原文。
martinfowler.com/bliki/Stran…
martinfowler.com/bliki/Branc…
三、法-重建计划规划和流程
定制重构的方针，划定重构的规模，评价影响，与团队达成一起。
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》
《重构：改善现有代码的规划（第二版）》
