简介
本文以云智慧数字化运维数据平台DODB产品为例，由云智慧研发团队通过分析对比产品历史版本与新版本中的Java代码行数、Java文件个数、代码注释占比、发布包大小、组件依赖等关键数据，找寻出历史版本开发过程中存在的代码、项目管理及开发人员等方面问题，最终梳理总结出改造代码、制定规范等可提升研发效能的有效方法。
一、数据对比
通过下方图表数据可以看出，在新版本中，代码注释占比降低了近150%，项目分支数减少了近100%，其他各项数据也均有了明显的变化。
代码行数统计
过去
代码注释比例
过去 现在sonar扫描
过去
现在
数据汇总对比
| 指标 | 过去 | 现在 | 对比结果 |
|---|---|---|---|
| 项目module数量 | 12 | 8 | 减少33% |
| 代码总行数 | 174252 | 136484 | 减少22% |
| Java代码行数 | 90310 | 50719 | 减少44% |
| Java文件个数 | 982 | 583 | 减少41% |
| 代码注释占比 | 3% | 7% | 提升133% |
| sonar-bugs数量 | 92 | 0 | 减少100% |
| 对外http接口数量 | 160 | 100 | 减少37.5% |
| 对外dubbo接口数量 | 100 | 25 | 减少75% |
| 发布包大小 | 226M | 170M | 减少25% |
| 项目分支数 | 300(参考) | 20 | 减少93% |
| 写入性能(单条10K) | 88W/min | 187W/min | 提升113% |
| 组件依赖 | ignite、vertx | 删除ignite、vertx | 5.3.1以redis替换ignite，彻底删除vertx |
| 微服务 | 1 | 3 | 5.3.1支持服务以存储模块或者非存储模块独立运行 |
通过上述各项数据的对比分析，本章节对历史版本开发中存在的代码、项目管理、开发人员等各方面问题进行了回顾分析，详细可查看下文：
代码侧问题
项目module数量多，部分不再使用的模块仍存在；
各module模块没有统一的包名区分，导致大量全限定名一致的类存在，加载顺序不一致引发各种问题；
项目中存在大量不再使用的代码块，增加了新人的学习成本及排查问题难度；例如dubbo接口，外部仅使用25个，对外提供了100个；
项目中重复代码较多，相似业务复制粘贴现象较严重，维护成本较高；
重复造轮子较多，如HttpclientUtil等；
注释率不够，大量代码无注释，无测试用例；
Vertx框架改造为SpringBoot容器不彻底，仍有众多Vertx逻辑和Springboot共存；
增加新模块需要写很多sql，需要手动编写Controller、Service、Dao层的“基础”代码；
项目依赖ignite组集群，导致服务是有状态的，大多人员对ignite不熟悉，导致解决问题较困难；
项目module数量多，部分不再使用的模块仍存在；
各module模块没有统一的包名区分，导致大量全限定名一致的类存在，加载顺序不一致引发各种问题；
项目中存在大量不再使用的代码块，增加了新人的学习成本及排查问题难度；例如dubbo接口，外部仅使用25个，对外提供了100个；
项目中重复代码较多，相似业务复制粘贴现象较严重，维护成本较高；
重复造轮子较多，如HttpclientUtil等；
注释率不够，大量代码无注释，无测试用例；
Vertx框架改造为SpringBoot容器不彻底，仍有众多Vertx逻辑和Springboot共存；
增加新模块需要写很多sql，需要手动编写Controller、Service、Dao层的“基础”代码；
项目依赖ignite组集群，导致服务是有状态的，大多人员对ignite不熟悉，导致解决问题较困难；
没有强有力的规范无法支撑更多的成员高效的协同开发；
分支管理无规范，导致分支数过多，活跃分支数量少，几百个分支维护困难；
以分支形式交付，交付后分支仍有提交，导致追踪发版版本困难；
无代码管理规范，多次出现功能遗漏、多功能等导致分支回退；
没有代码review制度，无法保障代码质量，冲突强行解决的问题时有发生；
没有强有力的规范无法支撑更多的成员高效的协同开发；
分支管理无规范，导致分支数过多，活跃分支数量少，几百个分支维护困难；
以分支形式交付，交付后分支仍有提交，导致追踪发版版本困难；
无代码管理规范，多次出现功能遗漏、多功能等导致分支回退；
没有代码review制度，无法保障代码质量，冲突强行解决的问题时有发生；
大多成员对代码不够熟悉，或仅熟悉部分代码；
很多成员不敢修改代码，更不敢删除代码；打着不影响其它功能的旗号，复制粘贴大量的重复代码和逻辑，导致维护困难；
早期代码设计较为合理，随着人员不断增加，很多代码重copy轻设计，只求完成功能，不考虑维护性拓展性，毫无设计可言；
部分人员git不熟练，导致强行覆盖远程分支的情况时有发生，无权限管控；
大多成员对代码不够熟悉，或仅熟悉部分代码；
很多成员不敢修改代码，更不敢删除代码；打着不影响其它功能的旗号，复制粘贴大量的重复代码和逻辑，导致维护困难；
早期代码设计较为合理，随着人员不断增加，很多代码重copy轻设计，只求完成功能，不考虑维护性拓展性，毫无设计可言；
部分人员git不熟练，导致强行覆盖远程分支的情况时有发生，无权限管控；
全限定名完全一致的类
全限定名完全一致的类
重复造轮子
重复造轮子
三、解决问题方案
为解决产品历史版本开发过程中存在的代码、项目管理等各方面问题，云智慧研发团队制定了开发、接口等相关规范；同时，通过限制代码仓库权限等其他操作也保证了规范的严格执行。
制定相关规范
无规矩不成方圆，切实可行的规范是保障团队战斗力的前提。规范制定应本着提高团队水平，又不限制成员积极性为目标。
开发规范
DODB接口规范
开发规范实行计划
DODB版本tag命名规范
开发设计模板
提测模板
会议规范
开发规范
DODB接口规范
开发规范实行计划
DODB版本tag命名规范
开发设计模板
提测模板
会议规范
工欲善其事必先利其器，规范里提供了相应的工具，用好可达到事半功倍的目的；同时有相关提交流程保障规范落地，不能让规范流于形式。
设置gitlab权限，保障强制代码review禁止任何人向保护分支提交代码，必须走merge流程
merge列表界面
merge详情界面
禁止删除tag
标签tag列表
标签tag详情
四、如何对现有代码进行改造改造原则
不影响现有开发和交付进度，必须互不影响，类似于空中加油机，既要加油，飞机也不能停；
保证兼容性升级，改造后原有数据和业务不受影响；
对外接口(如dubbo)原则上不能修改，保证调用方功能正常，特殊情况可沟通配合（如dubbo方法重载必须修改）；
不需要的代码一律删除，以后需要从历史版本找回，禁止批量注释掉代码；
代码设计要遵循 高内聚低耦合的原则，保证可重用性、移植性；
目标一致，改造循序渐进，保证充分测试。
不影响现有开发和交付进度，必须互不影响，类似于空中加油机，既要加油，飞机也不能停；
保证兼容性升级，改造后原有数据和业务不受影响；
对外接口(如dubbo)原则上不能修改，保证调用方功能正常，特殊情况可沟通配合（如dubbo方法重载必须修改）；
不需要的代码一律删除，以后需要从历史版本找回，禁止批量注释掉代码；
代码设计要遵循 高内聚低耦合的原则，保证可重用性、移植性；
目标一致，改造循序渐进，保证充分测试。
对不再使用的代码直接删除，历史可在gitlog中查看，例如bdp-plugin-sdk、bdp-plugin-zabbix等模块直接删除；
集中解决重复造轮子的问题，对部分通用逻辑，如HttpClientUtils、db操作等使用已有工具类替换；
书写数据库代码繁琐，引入mybatis-plus操作mysql
对不再使用的代码直接删除，历史可在gitlog中查看，例如bdp-plugin-sdk、bdp-plugin-zabbix等模块直接删除；
集中解决重复造轮子的问题，对部分通用逻辑，如HttpClientUtils、db操作等使用已有工具类替换；
书写数据库代码繁琐，引入mybatis-plus操作mysql
<!-- mybatis-plus操作数据库 -->
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus</artifactId>
<version>${mybatis-plus.version}</version>
</dependency>
对外dubbo接口bdp-rpc和bdp-rpc-model合并为bdp-rpc-core对外提供，通过编译各调用方项目，删除未使用的接口 彻底删除vertx和ignite依赖
| 模块名称 | 功能 | 包名前缀 |
|---|---|---|
| bdp-api | Restful API和业务逻辑实现、只能被bdp-standalone依赖 | com.cloudwise.bdp.api |
| bdp-base | 业务对象和接口定义 | com.cloudwise.bdp.base |
| bdp-commons | 通用工具common util | com.cloudwise.bdp.commons |
| bdp-pipeline | pipeline数据处理实现 | com.cloudwise.bdp.pipeline |
| bdp-rpc-core | rpc接口声明及rpc实体类定义，不能依赖其它模块，对外rpc接口请慎重修改 | com.cloudwise.bdp |
| bdp-standalone | 主项目，DODB主入口类为DodbServiceApplication | com.cloudwise.bdp.standalone |
| bdp-store-ck | ClickHouse存取实现 | com.cloudwise.bdp.store.ck |
| bdp-store-common | 数据层存储接口声明 | com.cloudwise.bdp.store.common |
/**
* github-api
* https://github.com/help/api/api_resources.md
*/
privatestaticfinal StringGITLAB_URL = "https://github.com/api/v4/projects/2393/repository";
privatestaticfinal StringPRIVATE_PARAM = "*****************";
/**
* 清理分支，已合并分支直接删除，其余删除前以tag形式备份
*/
@Test
publicvoidcleanBranches {
Map<String, Object> paramMap = Maps.newHashMap;
paramMap.put("private_token", PRIVATE_PARAM);
paramMap.put("per_page", 10086);
Stringbody = HttpUtil.get(GITLAB_URL + "/branches", paramMap);
List<Branche> branches = JSON.parseArray(body, Branche.class);
// 按最后一次提交时间由小到大排列
branches.sort(Comparator.comparingLong(o -> o.getCommit.getCommitted_date.getTime));
log.error("分支数量:{}", branches.size);
branches.forEach(item -> log.info("{}", item));
// 清理长期不活跃分支
.....
}
发布包进行瘦身
首先了解发布包是如何构建的，参看assembly.xml配置
发布包里有什么
<plugin>
<groupId>org.apache.maven.plugins </groupId>
<artifactId>maven-jar-plugin </artifactId>
<configuration>
<includes>
<include>com/cloudwise/bdp/** </include>
</includes>
<archive>
<manifest>
<addClasspath>true </addClasspath>
<mainClass>${start-class} </mainClass>
<classpathPrefix>../lib/ </classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
重点关注lib包，可从以下几个方面排查重点关注过大的包是否是项目必须的
是否有重复依赖问题
*例如netty-all是众多netty-的合集，不要去重复依赖，如果版本不一致还会引发问题；
batik-all是batik-*的合集，排除各个子包
排查后通过相关插件追查依赖源，精确排除
<plugin>
<groupId>org.apache.maven.plugins </groupId>
<artifactId>maven-dependency-plugin </artifactId>
<version>${maven.dependency.version} </version>
</plugin>
1、开发人员应清楚依赖包是做什么的，不要不管三七二十一依赖一堆没用的包，无谓增加发布包大小，还会带来隐患；
2、代码审核时，依赖文件(maven工程的pom.xml文件)的修改需要重点关注，禁止随意引入和修改依赖；
3、各产品线可在统一各依赖版本的基础上，调整构建方式，大幅减小集成包的大小。
改造总结
优化不求一步到位，可逐步进行，目标明确即可； 复杂是一切问题的根源，能用一行代码解决的问题，就不用两行； 一切功能都是靠代码实现的，写好代码很重要，不能把写好代码当成一件小事，只是为了完成所需功能而堆砌代码很简单，但编写清晰易懂且能完成所需功能的代码并不简单； 你永远无法编写出“完美”的代码，要用工具和流程规范来保证这一切，要充分测试；END
觉得不错，请点个在看呀