该文章900字，阅读需要2分钟
现状
2018年8月接手新项目后发现许多问题，该项目是一个7年以上的老项目，项目是基于JAVA开发的普通WEB工程，常年的开发jar包混乱，各种版本均有；其中一个比较严重，影响开发进度原因的就是代码管理、项目管理混乱导致的，长痛不如短痛，优化势在必行。
- 基于SVN版本控制，由于历史原因，版本控制混乱，trunk上掺杂有未上线的代码，导致每次打包需要每个文件去查找筛选，并且分析单个文件的历史版本；
- 生产测试未分离，请求地址路径硬编码耦合在代码里面，每次打测试包、 生产包需要不断的在对应服务器上寻找配置文件替换，出现过代码里面替换而服务器上配置文件没有替换，造成下次上线配置被覆盖；
- 多版本开发，测试服务器需要部署多套应用，多个日志路径、定时任务配置等混乱交错；
- 普通javaweb工程，188个jar包、2M带宽，代码检出、分支切换耗时通常以小时计算，效率十分低下
基于以上原因，打包过程繁琐，常常由专人操作，导致依赖过重，一但遇到打包人员休假等情况显得非常被动，且每次打包耗时较久，大版本上线常常需要多个人配合打包，开发体验极差。
分析
通过现状，分析后发现问题集中在两个地方
- 项目版本管理问题，尤其是多分支、版本交错的情况下，如何快速打包合并代码
- 项目工程管理问题，开发、测试、生产环境的分离，代码中地址、路径的剥离、解耦
改进
项目版本管理问题
版本管理计划由之前SVN转为GIT，9月初先将SVN-trunk的版本迁移到GIT，让组员先熟悉GIT的基本使用，冲突解决，多版本协作开发等；
之后12月份初正式将代码迁移至GIT，目前餐食、电票等版本均在git开发，项目组之间约定好版本命名、分支合并、提交注释的规范，如图：
图片1.png
项目工程管理问题
项目由普通web工程转为MAVEN工程，前期由组员交流分享了MAVEN入门知识，目前项目已经转为MAVEN管理，如图：
图片2.png
普通WEB工程转MAVEN过程实施步骤
- 借鉴藏航pom.xml，拿过来修改，新增包上传私服；后面发现jar包出入较大，逐一排查较为麻烦；
- 将188个包分配下去，每个人找对应的依赖；整合后，发现依赖有错误，依赖传递没有屏蔽，包版本没有核对，重复包没有删除，最终整合后包144个远低于188；
-
根据一二步的结果，整合后同188包逐一比较，排除重复包，包处理结果如图：
图片3.png
-
整理项目中的配置文件，同生产服务器（config.bak.*.0）每次替换文件比对后applicationContext-quartz filecenter log4j proxool sysconfig ftpcfg 等文件存在生产测试环境一致性问题；ServicesLocator.java\ContactMobileServiceServiceLocator.Java(获取新旧官网电话号码存在硬编码) 需要对以上几点进行修改，先将硬编码提取到配置文件中，然后差异化的配置文件用maven-profiles进行分离
图片4.png
如何测试？
1、开发自测各个接口
2、测试进行全面的覆盖测试
3、打包比较，maven打包和之前打包出来的结果分析比对
网友评论