这是一个创建于 1890 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司的 Java 项目。3 个 Springboot 的 jar 包。前后端分离。
经历了外包、多个菜鸟的代码维护、产品经理或决策者任性添加需求、修改业务流程等一系列问题，导致现在问题很多很大。
那么我们如果要重新开始设计研发并且不影响业务使用，需要做哪些准备工作，以及注意哪些问题呢？目前的要求或者疑问有：
- 不影响业务开展和系统使用
- 数据库想重新设计，但旧系统是做数据迁移好还是做兼容比较好？
- 新项目一定要模块化，Spring Cloud 是否满足我们模块化的需求呢？
- 新项目一定要有一套相对理想的更新部署机制，以达到项目服务程序 7*24 不间断运行
9 条回复 • 2019-09-23 19:11:47 +08:00
 |
1
gonethen OP 点解一个回复都冇啊😩
|
 |
2
lhx2008 2019-09-21 20:33:04 +08:00  1
springcloud 不一定是好的方案，如果总共就 3 个 springboot 包，其实没必要搞。。微服务现在都开始流行 K8S 了，不过鉴于没有运维能力，K8S 也不好。
数据库，新代码要向后兼容，表重不重新设计都行，否则到时候灰度发布 /回滚的时候，业务可能不可用 发布机制用 Jenkins 搞一下就行，后面慢慢再加 所以，还是先把问题梳理出来，再做优化。 |
|
3
gonethen OP @lhx2008
1. 现在是 3 个 jar 包，但如果想实现模块化是不是就要拆分多个 jar 包？是不是就需要用 Spring Cloud ？ 2. k8s 这个没了解过，我会去了解一下 3. jenkins 已经开始研究了，看来这个是自动化部署的普选方案 |
 |
7
zhazi 2019-09-22 13:47:27 +08:00 via Android 1
没看出你为什么要重构，为什么要模块化，我只能从字里行间看出这个项目的实现和你理解的不一致，然后强迫症发作决定要重构。
下面说说如何重构，讲完之后看你还想不想重构。 找出当前项目里的一个业务点，写测试用例，集成用例，正反测试，保证当前业务不会有一些 bug，保证全绿的情况下可以重构了。用你的实现替换了老的代码测试全通过，再再优化完代码测试通过就可以废弃老的代码了。 当你把所有业务点都经过上面的步骤后你就重构了整个项目。 重构从来不是什么大刀阔斧该架构，重构是抽丝剥茧。 至于你说的是重写项目，不像是重构项目 |
|
8
gonethen OP @zhazi #7
1. 为什么模块化？因为现在每次更新，整个业务系统不能使用，我认为模块化之后可以实现局部更新，使影响降低增强用户体验。 2. 为什么重构？不论是重构还是重写，我觉得都需要大刀阔斧地去改，因为老代码写的实在是太乱太烂了，我确实有强迫症。 3.无论怎么重构、怎么测试，我自己的前提也是不影响旧业务系统的正常使用。而且，新旧系统之间除了数据共享其他都要做到互不影响。当然，在重构期间有新的需求过来的话，问题就比较棘手了，我貌似必须要在新旧系统里写两遍 |
 |
9
IMCA1024 2019-09-23 19:11:47 +08:00
emm 也要考虑模块化后产生的问题噢
|
Select Language