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

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

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

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

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

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

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

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

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

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

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

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

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

文章目录
  1. 一、项目依赖管理混乱问题的背景
  2. 二、项目依赖管理混乱的原因有哪些
  3. 三、针对这些原因,如何切实有效地解决问题