项目依赖管理混乱问题之解决

一、项目依赖管理混乱问题的背景

刚加入公司那会儿，安逸了两周后，一次开会说月底前必须要有一个最小MVP产品可以演示来看，于是从那天以后，整个部门的氛围就开始紧张很多，因为一旦没出来，部门团队就非常有可能面临解散。对于那个时候，公司研发很多规范都没有真正的落实，例如编码规范、开发规范、设计规范、测试规范、运维规范等都是一片模糊。那个时候对于我们团队而言，为了尽早做出一个成品，有些规范可以暂时放弃，因为太过拘束于规范，反而受制于其，这样会造成很多时间上的消耗，而时间对于那个时候我们团队而言非常珍贵。

二、项目依赖管理混乱的原因有哪些

项目依赖管理混乱，主要体现pom.xml。事后我做了一些总结归纳，原因可分为如下:

• 技术选型未深入人心(这个未深入人心指的是团队对于技术选型的共识有分歧)；
• 每个人都有自己对Maven的理解，没有具体的统一的规范形成约束，导致每个人为了更快实现功能疯狂地引入各式各样的第三方框架包；
• 没有深刻地理解Java，仅仅是API的搬运工(虽然我很不愿意承认这一点，但这是事实)；
• 主人翁意识缺乏(原因在于研发流程上存在问题，我们无需懂更多具体的业务，只需按部就班的参照数据建模复制SQL以及参照接口文档组装数据即可，因为设计层面上有任何问题或是SQL有任何问题都与我们无关，我们只需实现就行，至于质量上的优劣与我无关)。

但这些原因存在都有其客观的背景，就像前面所说的那样，如果让每个人都走熟悉业务、梳理业务、相关数据库表设计、编写SQL、编写接口、前后端联调等这样的流程，最终可能会导致那个月东西出不来，最后团队可能就拜拜了。最后只能由最懂业务且来的较早的两个人进行相关的库表设计和sql编写，而我们研发只需参照数据建模复制SQL以及参照接口文档组装数据即可。但这必须只能是短期的，不能是长期的，长期的如此的话会导致很多问题，特别是对于技术人员来说，技术这东西每个人花点时间，基本上都能学会怎么用，但业务上的熟悉和深刻理解是需要时间的，而这个时间的长度是大于技术人员学习技术的时间长度。做技术的朋友都知道一点，技术仅仅是实现业务的一种方式，一旦离开了业务，技术就成了无本之木、无根之水了。一旦在一家公司长久的不较为深入的接触业务、熟悉业务、理解业务，那么是很不利的，因为在非技术型公司，一个技术人员如果只会技术，那么他是很容易被替代的。当然了，这里不是宣扬”技术无用论”，相反，我向阐述的一点就是，如果你想在一家公司长久地干下去(三年或三年以上)，那么一定是要懂业务的，不然的话，不仅仅位置上难以提升，薪资也是如此。

三、针对这些原因，如何切实有效地解决问题

知道了原因后，我是如何做的呢？我跟项目经理要了一些时间，那些时间主要花在解决历史遗留问题(也可以理解为技术债务)，而其中这个项目遗留问题就是历史遗留问题之一的。我所做的并不复杂，可归纳为如下:

• 第一、切分支(小步前进，减少大面积改动造成不可控的危害)；
• 第二、从头过项目，理解各个微服务之间的关系；
• 第三、在确认理解各个微服务之间的关系后，从大的pom.xml开始统一规范；
• 第四、统一了大的pom.xml后，按照微服务之间的关系，从网关到各个微服务的pom.xml依次抽取和移除；
• 第五、启动并进行几个接口测试(一次自测)，无问题后，打包发布测试环境；
• 第六、登录前台界面系统进行操作(相当于二次自测)；
• 第七、告知测试主管让其安排人进行功能测试；
• 第八、测试反馈无问题后，合并主分支并发布生产。

当然了，至今对于Maven的依赖管理，团队部分成员并未深刻理解，而我会Review对应成员的代码，告知其这样的做法是不合理的，并让其纠正。但这样并非问题的根本解决之道，以后仍然会再度重现。我思考了很多，觉得只有两点或许能根本解决:

• 第一、技术评审(部门领导主导，各研发成员参与，用于统一共识)；
• 第二、代码Review(好的宣扬，坏的引以为鉴，给写代码的人制造一定的压力，让其不要觉得写了之后就什么都不管了)。

而这两点是我上家某教育SaaS公司技术部门的多年实践。这两点会促使代码的可读性、可扩展性、可重用性的提高，很容易就达到高内聚低耦合。