苦搞一天半项目接口迁移的思考
方向错了，工程量会很大，除非对项目了熟于心
最近公司的一个项目要和其他组做对接，我们要将自己常用的一些接口迁移出来
然后同事给我拉了最新的代码，参照着之前的某一个分支的来搞项目迁移
之前没有做过项目迁移的事情，想着也就copy一下类到新项目中，事实证明，我想的太简单了
一开始，在我将我们要迁移的三个接口copy到新项目中后，在参照着之前的项目在pom文件中配置了微服务和谷歌手机号查询的依赖，然后jar包冲突
我之前没有遇到过类似的jar包冲突，我也不知道怎么会冲突（因为我是一个个copy的）
在使用Maven Helper插件后通过排除解决了全部冲突，但我感觉这样是不对的，因为我对公司的pom文件进行了很人为的修改
又摸索了半天时间后，我发现新项目的Spring Boot的版本竟然和之前不一致，我没有对同事给我的模版进行检查，错误的认为同事给我的就是可以的代码，这是其中的教训之一：你的前提可能不对，也可以叫适当质疑权威，哪怕是有经验的同事给你的模版
然后修改版本后，还是爆红，后面又请教同事，同事说直接把之前的pom文件和配置文件全部复制来，然后按照这种做法，项目是没有爆红了，所以另一个教训就是：尽量复用之前的依赖，因为那是公司实践下来的，哪怕会冗余，而我过于追求理想状态了
后面Jar包不报错了，但是各种类的冲突，依赖关联，我按照同事的说法：把报错的东西删掉
我也的确这样做的，但是删了一个之后，其关联的太多了，经常误删我们需要的东西，然后我git返工了两次，第三次是我觉得要最小可行性删除报错，只把报错的那一行删掉，事实证明，我又错了。
图（因为删除不全面导致类的注入出现问题）：
因为有些地方我删了之后，其他的地方spring要自动注入时经常找不到，导致一直卡在这里
工程量太大了，因为不是一个分支下的迁移，所以有的类可能都变了不少，而我对项目的整体结构没有很清晰的全局性的认识，所以我放弃了，可能是个明智的做法。
但我觉的这次项目迁移过程中最重要的一点是大方向就错了，我觉得不是一个分支下的迁移注定徒劳，我感觉自己这一天半的时间都浪费在这种无意义的删除代码，构建上面，这可能是我学到的最大的教训：当我们觉得一件事情没有很大的意义时，我们不能闷头埋在里面，可能会使我们越走越远，最后陷入不好的情绪，进一步影响自己
总结一下：
- 在拿到一个需求后，先看给的前提有没有可能出错，在本次项目中可以说不同分支的项目迁移（注定工程量不小），Spring Boot版本的大前提
- 尽量不要把对公司的pom依赖做随意的修改
- 对Maven的一些基本操作了解不全面
- 发现自己离目标越走越远时，及时求助同事调整和适当放弃
