如何更好的项目重构？

[gonethen]

公司的 Java 项目。3 个 Springboot 的 jar 包。前后端分离。

经历了外包、多个菜鸟的代码维护、产品经理或决策者任性添加需求、修改业务流程等一系列问题，导致现在问题很多很大。

那么我们如果要重新开始设计研发并且不影响业务使用，需要做哪些准备工作，以及注意哪些问题呢？目前的要求或者疑问有：

1. 不影响业务开展和系统使用
2. 数据库想重新设计，但旧系统是做数据迁移好还是做兼容比较好？
3. 新项目一定要模块化，Spring Cloud 是否满足我们模块化的需求呢？
4. 新项目一定要有一套相对理想的更新部署机制，以达到项目服务程序 7*24 不间断运行

[gonethen]

点解一个回复都冇啊😩

[lhx2008]

springcloud 不一定是好的方案，如果总共就 3 个 springboot 包，其实没必要搞。。微服务现在都开始流行 K8S 了，不过鉴于没有运维能力，K8S 也不好。
数据库，新代码要向后兼容，表重不重新设计都行，否则到时候灰度发布 /回滚的时候，业务可能不可用
发布机制用 Jenkins 搞一下就行，后面慢慢再加
所以，还是先把问题梳理出来，再做优化。

[gonethen]

@lhx2008
1. 现在是 3 个 jar 包，但如果想实现模块化是不是就要拆分多个 jar 包？是不是就需要用 Spring Cloud ？
2. k8s 这个没了解过，我会去了解一下
3. jenkins 已经开始研究了，看来这个是自动化部署的普选方案

[lhx2008]

@gonethen #3 模块化之后，除了调用多几次序列化反序列化，带来了什么好处？

[gonethen]

@lhx2008 #4 可以平滑更新使影响降到最低？

[lhx2008]

@gonethen #5 平滑更新用灰度发布就可以。就是最简单手工部署来说，就是起两个，等第二个起好了再切过去，也没问题吧。

[zhazi]

没看出你为什么要重构，为什么要模块化，我只能从字里行间看出这个项目的实现和你理解的不一致，然后强迫症发作决定要重构。
下面说说如何重构，讲完之后看你还想不想重构。
找出当前项目里的一个业务点，写测试用例，集成用例，正反测试，保证当前业务不会有一些 bug，保证全绿的情况下可以重构了。用你的实现替换了老的代码测试全通过，再再优化完代码测试通过就可以废弃老的代码了。
当你把所有业务点都经过上面的步骤后你就重构了整个项目。
重构从来不是什么大刀阔斧该架构，重构是抽丝剥茧。
至于你说的是重写项目，不像是重构项目

[gonethen]

@zhazi #7
1. 为什么模块化？因为现在每次更新，整个业务系统不能使用，我认为模块化之后可以实现局部更新，使影响降低增强用户体验。
2. 为什么重构？不论是重构还是重写，我觉得都需要大刀阔斧地去改，因为老代码写的实在是太乱太烂了，我确实有强迫症。
3.无论怎么重构、怎么测试，我自己的前提也是不影响旧业务系统的正常使用。而且，新旧系统之间除了数据共享其他都要做到互不影响。当然，在重构期间有新的需求过来的话，问题就比较棘手了，我貌似必须要在新旧系统里写两遍

[IMCA1024]

emm 也要考虑模块化后产生的问题噢