2个动作,让研发效率提升120%,代码减少50%

简介

本文以云智慧数字化运维数据平台DODB产品为例,由云智慧研发团队通过分析对比产品历史版本与新版本中的Java代码行数、Java文件个数、代码注释占比、发布包大小、组件系统运维是干嘛依赖等关键数据,找寻出历史版本开发过程中存在的代码、项目管理及开发人员等方面问题,最终梳理总结出改造代linux删除文件命令码、制定规范等可提升研发效能的有效方法。

一、数据对比

通过下方图表数据可以代码生成器看出,在新版本中,代码注释占比降低了近150%,项目分支数减少了近100%,其他各项数据也均系统运维工程师有了明显的变化。

代码行数统计

  • 过去
  • 现在


                                            2个动作,让研发效率提升120%,代码减少50%

代码注释比maven滑板

  • 过去


                                            2个动作,让研发效率提升120%,代码减少50%

  • 现在


                                            2个动作,让研发效率提升120%,代码减少50%

sonar扫描

  • 过去


                                            2个动作,让研发效率提升120%,代码减少50%

  • 现在


                                            2个动作,让研发效率提升120%,代码减少50%

数据汇总对比

指标 过去 现在 对比结果
项目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支持服务以存储模块或者非存储模块独立运行

二、历史问题回顾

linux必学的60个命令过上述各项数据的对比分析,本章节对历史版本开发中存在的代码、项目管理linux系统安装、开发人员等各方面问题进行了回顾分析,详细可查看代码编程教学下文:

代码侧问系统运维主要做什么

  • 项目module数量多,部分不再使用的模块仍存在;

  • 各module模块没有统一的包名区分,导致大量全限定名一致的类存在,加载顺序不一致引发各种问题;
  • 项目中存在大量不再使用的代码块,增加了新人的学习成本及排查问题难度;例数据分析如dubbo接口,外部仅使用25个,对外提供了100个;
  • 项目中重复代码较多,相似业务复制粘贴现象较严重,维护成本较高;
  • 重复造轮子较多,如HttpclientUtilinux系统安装l等;
  • 注释率不够,大量代码无注释,无测试用例;
  • Vertx框架改造为SpringBoot容器不彻底,仍有众多Vertx逻辑和Sprinmaven配置了本地仓库还是去下载远程gboot共存;
  • 增加新模块需要写很数据分析师多sql,需要手动编写Controller、Service、Dao层的“基础”代码;
  • 项目依赖ignite组maven安装教程集群,导致服务是有状态的,大多人员对ignite不熟悉,导致解决问题较困难;

项目管理侧问题

  • 没有强有力的规范无法支撑更多的成员高效的协同开发;

  • 分支管理无规linux系统范,导致分支数过多,活跃分支数量少,几百个分支维护困难;
  • 以分支形式交付,交付后分支仍有提交,导致追踪发版版本困难;
  • 无代码管理规范,多次出现功能遗漏、多功能等导致maven配置了本地仓库还是去下载远程分支回退;
  • 没有代码review制度,无法保障代码质量,冲突强行解决的问题时有发生;

开发人员侧问题

  • 大多成员对代码不够熟悉,或仅熟悉部分代码;

  • 很多成员不敢修改代码,更不敢删除代码;打着不影响其它功能的旗号,复制粘贴大量的重复代码和逻辑,导致维护困难;
  • 早期代码设计较为合理,随着人员不断增加,很多系统/运维代码重copy轻设计,只求完成功能,不考虑维护性拓展性,毫无设计可言;
  • 部分人员git不熟练,导致强行覆盖远程分支的情况时有发生,无权限管控;

部分问题示例

  • linux系统限定名完全一致的类


                                            2个动作,让研发效率提升120%,代码减少50%


                                            2个动作,让研发效率提升120%,代码减少50%

  • 重复造轮子


                                            2个动作,让研发效率提升120%,代码减少50%

三、解决问题方案

为解决产品历史版本开发过程中存在的代码、项目管理等各方面问题,云智慧研发团队制定了开发、接maven配置了本地仓库还是去下载远程口等相linux系统关规范;同时,通过限制代码仓库权限等其他操作也保证了规范的严格执行。

制定相关规范

无规矩不成方圆,切代码图片实可行的规范是保障团队战斗linux命令力的前提。规范制定应本着提高团队水平,又不限制成员积极性为目标。

  • 开发规范

  • DODB接口规范
  • 开发规范实行maven配置计划
  • DODB版本tag命名规范
  • 开发设计模板
  • 提测模板系统/运维
  • 会议规范

保障规范严格执行

工欲善其事必先利其器,规范里提供了相应的工具,用好可达到事半功倍的目的;同时有相关提交流程保障规范落地,不能让规范流于形式linux系统

  • 设置gitlab权限,保障强制代码review

禁止任何人向保护分支提代码软件交代码,必须走merge流程


                                            2个动作,让研发效率提升120%,代码减少50%

merge列表界面


                                            2个动作,让研发效率提升120%,代码减少50%

merge详情界面


                                            2个动作,让研发效率提升120%,代码减少50%

  • 完成后远程分支强制删除


                                            2个动作,让研发效率提升120%,代码减少50%

  • 以ta数据漫游是什么意思g追踪生产交付,要求测试交付时一定要有tag


                                            2个动作,让研发效率提升120%,代码减少50%

禁止删除tag


                                            2个动作,让研发效率提升120%,代码减少50%

标签tag列表


                                            2个动作,让研发效率提升120%,代码减少50%

标签taglinux详情


                                            2个动作,让研发效率提升120%,代码减少50%

四、如何对现有代码进行改造代码编程入门

改造原则

  • 不影响现有开发和交付进度,必须互不影响,类似于空中加油机,既要加油,飞机也不能数据漫游停;

  • 保证兼容性升级,改造后原有数据和业务不受影响;
  • 对外接口maven环境配置(如dubbo)原则上不能修改,保证调用方功能正常,特殊情况可沟通配合(如dubbo方法重载必须修改);
  • 不需要的代码一律删除,以后需要从历史版本找回,禁止批量注释掉代码;
  • 代码设计要遵循 高内聚低耦合 的原则,保证可重用性、移植性;
  • 目标一致,改造循序渐进,保证充分测试。

部分改造逻辑

  • 对不再使用的代码直接删除,历史可在gitlog中查看,例如bdp-plugin-sdk、bdp-plugin-zabbix等模块直接删除;

  • 集中解决重复造轮子的问题,对部分通用逻辑,如HttpClientUtils、db操作等使用已有工具类替换;
  • 书写数据库代码繁琐,引入mybatis-plulinuxs操作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依赖


                                            2个动作,让研发效率提升120%,代码减少50%


                                            2个动作,让研发效率提升120%,代码减少50%

  • 对各maven仓库module的功能和命linux是什么操作系统名做了统maven滑板一规范,对原有代码做统一修改调整
模块名称 功能数据漫游是什么意思 包名前缀linux系统安装
bdmaven环境配置p-api Restful API和业务逻辑实现、只能被bdp-standalone依赖 co数据漫游m.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-rp代码随想录c-core rpc接口声明及rpc实体类定义,不能依maven配置赖其它模块,对外rpc接口请慎重修改 com.cloudwise.bdp
bdp-standalone 主项目,DODB主入口类为DodbServiceApplication com.cloudwise.bdp.standalone
bdp-store-ck ClickHouse存取实现 com.cloudwise.bdp.store.ck
b数据废土dp-store-common 数据层存储接口声明 com.cloudwise.bdp.sto数据re.common
  • 调用gitlab-api对长期代码编程入门不活跃分支集中清理备份
 /**
 * github-api
 * https://github.com/help/api/api_resources.md
 */
private static final String GITLAB_URL = "https://github.com/api/v4/projects/2393/repository";
private static final String PRIVATE_PARAM = "*****************";
 /**
 * 清理分支,已合并分支直接删除,其余删除前以tag形式备份
 */
@Test
public void cleanBranches() {
    Map<String, Object> paramMap = Maps.newHashMap();
    paramMap.put("private_token", PRIVATE_PARAM);
    paramMap.put("per_page", 10086);
    String body = 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配置

  • 发布包里有什linux必学的60个命令


                                            2个动作,让研发效率提升120%,代码减少50%

  • 不要把配置文件重复打入jar包中
<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包,数据透视表可从以下几个方面排查

重点关数据标注注过大的包是否是项目必须的


                                            2个动作,让研发效率提升120%,代码减少50%

是否有重复依赖问题

*例如netty-all是众多netty数据漫游-的合集,不要去重复依赖,如果版本不一致还会引发问题;**maven仓库


                                            2个动作,让研发效率提升120%,代码减少50%

batik-数据漫游all是batik-*的合集,排除各个子包


                                            2个动作,让研发效率提升120%,代码减少50%

排查后通过相关插件追查依赖源,精确排除

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-dependency-plugin</artifactId>
   <version>${maven.dependency.version}</version>
</plugin>

1、开发人员应清楚依赖包是做什么的,不要不管三七二十一依赖一堆没用的包,无谓增加发布包大小,还会带来系统/运维隐患;

2、代码审核时,依赖文件(maven工程的数据分析pom.xml文件)的修改需要重点关注,禁止随意引入和修代码图片改依赖;

3、各产品线可在统一各依赖版本的基础上,调整代码生成器构建方式,大代码生成器幅减小集成包的大小。

改造总结

  • 优化不求一步到系统运维主要做什么位,可逐步进行,目标明确即可;
  • 复杂是一切数据恢复问题的根源,能用一行代码解决的问题,就不用两行;
  • 一切功能都是靠代码实现的,写好代码很重要,不能把写好代码系统运维工作内容当成一件小事,只是为了完成所需功能而堆砌代码很简单,但编写清晰易懂且能完成所需功能的代码并不简单;
  • 你永远无法编写出“完美”的代码,要用工具和流程规范来保证这一切,要充分测试;