系统重构与新旧系统切换方案概述

什么是系统重构

它是一套严谨而安全的过程方法，它通过一系列行之有效的方法与措施，保证软件在优化的同时，不会引入新的BUG，保证软件改造的质量。
系统重构，就是在不改变软件的外部行为的基础上，改变软件内部的结构，使其更加易于阅读、易于维护和易于变更。

系统重构，在我理解有一种是系统内部的重构，也就是既有代码，还有一种是推翻老系统，建立一套新系统。

系统重构原则和方法

1、建议采用“迭代式”重构。
考虑将一次重构拆分为多次“迭代”行为，然后每一个重构步骤能快速部署上线并得到反馈，以便评估重构的效果，及时作出调整。从项目风险的角度来说，通过将重构分成多个迭代，能有效的控制迭代的风险，每一个步骤，重构团队（开发和测试）都能集中一点吃透，并进行充分的测试。如果直接将重构1，2个月后的版本，一下丢给测试同学去验证，效果可见一斑。

至于如何来拆分重构，并没有一个统一的标准，但是我个人的看法，每次重构的工作量，不应该超过1个正常的迭代（2周时间）。

2、对系统着手重构前，以及在系统开发中，都要提前考虑好切换方案以及方案在执行过程中的落地。新系统做好了，和老系统无法兼容，没有好的迁移方案，最后卡这了，系统推不去，对团队是一个很大的打击。

系统重构可以参考两本书：《重构-改善既有代码的设计》，《重构与模式》

系统重构可能面临的问题

1、新老系统功能的兼容。主要在于老数据，在新系统功能中可用、展现完整，并且可以按新功能继续向下走。对于旧系统识别到的一些坑，尽量避开就是。后期做测试，要更多的关注旧数据在新系统中的表现。

2、老数据迁移新系统后的数据完整性，若不完整，需要补充，否则新功能在展现旧数据时，会出现不可用的情况。比如由于表结构不一致，表字段不统一，新增的扩展数据等等。

3、若涉及到工作流审批，流程审批能否兼容。新旧切换前，有两个选择：一是可以全部走完老流程，二是将未走完的流程全部回退到起点，在新系统中重新发起审批，并自动推动到对应节点，再继续向下走。

4、老系统对外的接口在新系统中是否保持统一，否则要重新对外变更接口，比如端口、方法名、参数、返回值等等，尽量保持接口定义不变，造成不必要的麻烦。

5、确保新系统与外围系统的交互是否完整，新系统接替旧系统，与外围系统的交互同样要保留，不能新系统一上线，其他的系统服务涉及到旧系统的地方不可用。

6、针对一些特别老旧的系统，且在文档缺失严重的情况下，必须深入旧系统的使用、源代码逻辑，全面了解旧系统的功用，以便 能在新系统中完整的保持功能，不然容易学到了形，却遗漏了某些点。

7、迁移系统分主次，尽量避免统一迁移，而是逐步迁移

8.新老系统并存的架构