公司项目技术老旧，是种什么体验？

故事继续，在熟悉了整个系统之后，某一天我萌发了一个想法，何不做点技术栈的小更新？抱着试试看的想法，我先挑了最软的柿子捏，把 Java 6 干到了 Java 8，Tomcat 换到了最新版，非常顺利。在计划下一步行动前，我又把几百个编译警告都修正了，步子不能太大。

几周后，着手从 spring3 升级到 spring4，并没有做很多改动，稳定运行了一段时间后，顺手把大段 XML 配置替换成了 spring 注解，后来又更新到 spring5。到这个阶段，我感觉已经比大部分公司新了^_^。

然后我想改善一下打包发布，却发现 maven 太死，用 XML 写逻辑是很要命的，干脆把构建系统换成了 gradle，把构建脚本从大几百行缩短到了一百多行，功能不但没少，还多了。

我觉得还不够，尝试引入了 Koltin，原本只是想写一两个类感受一下，谁知道一试就出事了，出大事了，整个项目都被逐步逐步的替换成了 Kotlin，半年之后，除了自动生成的代码，没有一行是 Java 写的了。

这些变更，都是业余时间做的，并没有占用正常版本迭代时间，也没有因此引入 bug，反而整个系统更稳健和高效了。

之后的一段时间里，脑子里有个人不停的跟我说，重写吧，推倒重来吧。正好公司业务要求有大的调整，里应外合之下，重写已经是箭在弦上，不得不发了。

然后很自然的做了好多更新，


前后端完全分离，前端用 element 重写

拆分成十来个模块，变成独立的内部服务，分而治之，部分模块改用 PHP 了

零阻塞，完全丢掉 Tomcat 堆多线程那套做法，干脆 servlet 全丢，全面拥抱了 vertx

DI 和配置等脏活，仍然交给了 spring，直接从 springboot 1.X 最新版起步


最近我又抽空更新到了 springboot 2.0，计划十一之后再着手把 JRE 迁移到 Java 11，明年估计还有随 Kotlin 1.3 发布的 coroutine，都是值得试试手感的事情。


虽然这么折腾没带来什么账面收益，我也不图这个，起码我自己后续的开发和维护更加舒适了，很多常规工作，以前要 2 周工期的，后来变成了一周，后来变成了 2-3 天，现在最多半天能搞定，我可以有更多的时间做到更好。

简单回复一下一些疑问

Kotlin 和 Spring 怎么合体？
基本姿势跟 Java 一样，比 Java 多些语法糖红利。

Springboot 和 Vertx 怎么合体？
Vertx 官方有 example。

SpringMVC 能转 Vertx ？
当然能，但异步改造并不轻松，管理后台和低负载接口，仍然可以继续用 springmvc，或者用 vertx 提供的 blocking 方法线程池。

楼主不用做需求吗？
当然要做，初期可能略影响进度，积累一段时间之后，重构后节省的时间大大超过重构本身的时间。渐进式重构，讲究的就是少量多餐，保持克制再克制，一次不要改太多。