来聊聊我最近的工作都在干什么嘛。其实我这一个月的任务就是搬迁代码。把一个springboot项目的一个大模块功能迁移到我们项目中来。刚拿到这个任务的时候，心里想，不就是复制代码嘛，用不了多久，结果搞了一个月，还是太年轻了。总结一下我为啥搞了这么久。
其实ai也坑了我不少
我让他先把源项目相应功能的代码先找出来，然后copy到我们项目的对应位置。它复制过来首先第一个就不全，很多configuration类或者涉及到那些配置文件它都没找全。还有就是他不能处理错误的import，因为代码复制过来，路径变了它不知道咋处理了。还有一个比较坑的点他找不到一些类的时候自己去重写，但我想要的是源项目一样的类。反正它这么一搞我的工作只增不减。还有就是我让claude code帮我回退代码，结果他把我暂存区的代码都删了，我其实只想让他回退本次的改动，所以在使用ai之前一定要commit一下代码，教训已经摆在这了。然后也总结一下让ai copy代码完全是一个错误的决定。要是我自己先把controller代码搬过来，然后按缺失的类去找也用不了多久，而且我不应该一股脑的把代码都搬过来然后去解决问题，而是应该先搬一个controller，测试一下整体是否可用，万一两个项目就是不兼容，那就前功尽弃了，虽然说我整体分析了一下搬过来处理一下是可以兼容的。
项目层级问题
由于之前是springboot项目，不用担心跨模块问题，找不到包。我现在的项目还是ssm项目，而且是分模块的，模块之间又有依赖，common模块，dao模块，service模块等等。所以挪过来之后还要考虑依赖关系。而且之前的包怎么拆比较好其实还得考虑一下，但我总体上按照了每个模块的功能去放对应的包，这也花了一些时间。
框架兼容问题
springboot项目搬到ssm项目很多东西还得调整一下，第一个就是要重新配置mybatis-plus，我们项目原来配的是mybatis，还是能兼容的。只是一个项目两个数据库框架配置有点别扭。配完是真的好用，再也不用像之前一样一个简单的功能查询还得写一个sql，直接用wrapper搞定。第二个问题就是自动配置的问题，springboot有很多自动配置机制，但是放在ssm项目就不适用，得换成繁琐的xml配置以及一些原始的bean的配置方式。比如extensionor框架。第三个就是版本兼容问题，源springboot项目用了5.1.2的spring，能够很好的兼容spring cloud的open feign，但是我的项目用的是4.3.15的spring，我又不好升级spring，这个升级影响比较大，所以我只能换成原始的feign调用。最后说一个小插曲，我们项目的数据库配置用了一个spring-datasource.xml文件，然后里面的Mapper扫描写的不规范，它扫了所有的的Mapper，导致公司内部的二方包的baseMapper和mybatisplus的baseMapper冲突了，然后我就想着排除一下路径，结果排除的属性又不支持，因为这个版本不支持exclude-filter的写法，我只能指定basepackage的方式去做了。总结下来springboot的自动装配机制真是一大进步啊！原先的项目很容易陷入配置炼狱，如果你对这些框架配置方式和版本依赖不熟悉的话，就可以卡住你很久。
公共组件的问题
源spingboot项目有redis，加密机，用户管理，发送消息短信和邮件的公共组件。我们项目都有，这些东西在公司内部都是以二方包以及系统调用的形式存在，其实都是一个东西，这样的话我把别人代码挪过来了还得换成我们的配置，总不能一个项目连两个redis配置吧。做这些工作又得捋清楚这些公共组件是怎么对接的，如果两个项目配的不一样又得怎么兼容进来，让项目快速跑起来。剩下的就是测每个controller的接口的业务功能。
总结
其实这个月收获也不少，因为做这些工作相当于你去搭建一套项目运行的环境，以及对boot项目和ssm项目的一些差异点有了更深的体会。比做简单的crud工作会更好一点，让我对项目的架构技术选型有了更深的了解。