用springboot重构一个五年前的项目是什么体验？（一）

最近把一个从2015年开发至今的一个个人项目从传统的spring彻底重构成springboot项目&＃xff0c;用了大概一个多月的时间&＃xff0c;里面的坑还是挺多的&＃xff0c;但是收获也是满满&＃xff0c;记录一下&＃xff0c;希望能帮助那些准备或者在做这一步的朋友&＃xff08;有任何问题都可以私信我&＃xff0c;非常乐意解答&＃xff09;。

为什么要重构&＃xff1f;

1. 原先spring架构可维护性越来越低

• 刚开始xml&＃43;配置文件的方式感觉没什么&＃xff0c;但是随着各种参数、动态配置的增加xml中引用properties中的变量使得开发人员维护变得越来越复杂&＃xff08;我一个人维护有时候都找半天&＃xff09;&＃xff0c; 而springboot的约定大于配置理念使配置基本框架配置变得清晰易维护
• springboot查问题更加简单&＃xff1a;由于配置都非常固定&＃xff0c;区别原先spring方式各种不同的配置&＃xff0c;亲测出错概率大大降低&＃xff0c;极大提升了维护性。
• 由于原生spring&＃xff0c;得自己管理各种jar包&＃xff0c;所以会出现各种jar包冲突等一些列的问题&＃xff0c;这大大降低了维护性&＃xff0c; 而springboot则有对应开发的starter&＃xff0c;各种版本都做到了统一&＃xff0c;出错概率也大大降低。

2. 集成新技术的成本变高

• 由于springcloud的发展&＃xff0c;springboot变成了一个基础的架构&＃xff0c;而如果还是沿用原来的spring xml配置的方式文档和资料变的越来越少&＃xff0c;机会成本也变大了。反观springboot资料变得越来越丰富集成一个新的框架或者替换都是分分钟的事情

3. 各种不同环境的问题依然时不时的会存在

• 由于原先spring的方式&＃xff0c;或多或少都会依赖外部的容器去做启动&＃xff0c;虽然刚开始可能没什么问题&＃xff0c;但是随着各种依赖以及开发和测试环境的不同&＃xff0c;偶尔会出现本地测试好好的&＃xff0c;而一发布到测试就会有各种问题&＃xff0c;而springboot内嵌容器就非常好的解决了这个问题&＃xff0c;容器被打包在了发布jar中&＃xff0c;隔离了不同环境因素&＃xff0c;使得发布出现问题的概率大大降低

4. 重构过程能对更多的技术细节进行深入学习

• 重构能迫使自己对原先的代码细节重新梳理&＃xff0c;思考原先架构的合理性
• 重构过程会对各种第三方依赖做梳理&＃xff0c;能够更好的了解细节
• 重构的过程遇到了很多的问题&＃xff0c;解决的过程恰恰是宝贵的财富

重构清单

• 项目结构重构

• 配置文件从原先的xml到完全properties

• 各类jar包从单独到结成starter方式的重构

• 单元测试保证重构后的系统功能

&＃xff08;一&＃xff09;项目结构重构