如何接手别人的系统-遗留系统重建的道法术器势志（万字长文） - 掘金
成熟的公司会有大量的存量系统，程序员难免接手他人开的的系统。万一不小心接手的系统过于腐烂，祖传代码难以破译，一边吃力不讨好艰难维护老系统，一边在上面做新业务，出了问题要背大锅，一头包，难有好成绩，满身疲惫，终成大冤种。本文尝试探讨如何接手遗留系统的方法论，重建遗留系统的道法术器势志，使得遗留系统跟上组织内系统演进和满足业务需求，逐步从泥沼中走脱。
什么是遗留系统？接手别人开发的系统，可以是各种原因导致的系统建设、维护工作的交接，对于接手人来说就属于是遗留系统；严格意义上来说任何已存在的系统都可以是遗留系统。
接手一个遗留的系统并非一定要重建它，如果是一个即将告别历史舞台的系统，我们没有必要讨论，只需要把它“送好最后一程”即可。本文讨论的范畴是遗留系统将要长期服役下去，并且会在上面发展更多业务，长出新功能的系统，也就是图中将遗留系统变成一个现代化的系统。
那么首先，在拿到交接的材料中基本了解系统后，我们从业务需求、系统功能、系统框架，特别是对系统设计有了整体的认识之后，我们就应该思考一个问题，该系统是否符合现代系统的要求，技术上应该延续现有设计，还是重构、重写、重搭、迁移。如果是延续现有系统设计，则本文往下就没有必要再往下看了。
当你认为该系统实在是烂，交到你手里维护你就要做大冤种了，这个时候就应该思考重建该系统的方法（套路）了，最好能做到私人订制。如何能做到私人订制？我们从业界成熟方法论说起，再以笔者经验实战情况，总结梳理出能抡的三板斧。希望能帮助到各位，若有帮助，请一键三连吧🤝。
以术载道，以道驭术，以法固道，善于驭器，勤于练术，术器生势，顺势成志。本文的内容较多，先来一览目录，源道法术器势志都包含哪些内容，随后再详细展开陈述。
首先要明确重构的动机，把动机详清楚，痛点在哪，拿出来和组内的同学一起讨论，切记要客观。是系统框架太老旧？还是系统架构难以为继？还是有很多坏代码的味道？还是因为系统太过复杂，没办法短时间内了解到全，出于处于懒惰，选择逃避？还是遗留系统太过腐烂，历经N手开发人员后，根本没有人员、文档、任何材料能支撑起你去认识该系统，导致你无法从旧系统中获得知识，所以想要尽快与遗留系统划清界限？
1.业务不能满足发展 从业务角度来说系统的能力无法支持业务发展的需要，功能设计落后于业务发展，需要改造现有功能的能力。
2.系统能力不能满足发展 如系统部署架构不能满足业务规模的发展，无法支撑用户量、访问量。
3.新需求交付时间长 在不了解的系统上做需求会遇上或多或少的未知情况，需要在不断踏坑、填坑中调整，完成任务的时间需要不断加长，交付时间常常比预估的要长。
4.缺陷多，到处救火 团队长期处于救火状态，每天白天做消防员，晚上做施工员。不管是业务团队还是技术团队都处于较大压力的工作环境中，长期以往精神状态会受到影响，不利于团队建设。
5.交付周期不可控，业务无法按期开展 由于第3、第4点导致交付工作的投入不足，需要延长排期计划，无法及时上线新需求，新业务也无法按计划开展。