写点什么

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

  • 2022 年 3 月 07 日
  • 本文字数:3529 字

    阅读完需:约 12 分钟

云智慧 AIOps 社区是由云智慧发起,针对运维业务场景,提供算法、算力、数据集整体的服务体系及智能运维业务场景的解决方案交流社区。该社区致力于传播 AIOps 技术,旨在与各行业客户、用户、研究者和开发者们共同解决智能运维行业技术难题,推动 AIOps 技术在企业中落地,建设健康共赢的 AIOps 开发者生态。

简介

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

一、数据对比

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

代码行数统计

  • 过去

  • 现在

代码注释比例

  • 过去

  • 现在

sonar 扫描

  • 过去

  • 现在

数据汇总对比


二、历史问题回顾

通过上述各项数据的对比分析,本章节对历史版本开发中存在的代码、项目管理、开发人员等各方面问题进行了回顾分析,详细可查看下文:

代码侧问题

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

  • 各 module 模块没有统一的包名区分,导致大量全限定名一致的类存在,加载顺序不一致引发各种问题;

  • 项目中存在大量不再使用的代码块,增加了新人的学习成本及排查问题难度;例如 dubbo 接口,外部仅使用 25 个,对外提供了 100 个;

  • 项目中重复代码较多,相似业务复制粘贴现象较严重,维护成本较高;

  • 重复造轮子较多,如 HttpclientUtil 等;

  • 注释率不够,大量代码无注释,无测试用例;

  • Vertx 框架改造为 SpringBoot 容器不彻底,仍有众多 Vertx 逻辑和 Springboot 共存;

  • 增加新模块需要写很多 sql,需要手动编写 Controller、Service、Dao 层的“基础”代码;

  • 项目依赖 ignite 组集群,导致服务是有状态的,大多人员对 ignite 不熟悉,导致解决问题较困难;

项目管理侧问题

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

  • 分支管理无规范,导致分支数过多,活跃分支数量少,几百个分支维护困难;

  • 以分支形式交付,交付后分支仍有提交,导致追踪发版版本困难;

  • 无代码管理规范,多次出现功能遗漏、多功能等导致分支回退;

  • 没有代码 review 制度,无法保障代码质量,冲突强行解决的问题时有发生;

开发人员侧问题

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

  • 很多成员不敢修改代码,更不敢删除代码;打着不影响其它功能的旗号,复制粘贴大量的重复代码和逻辑,导致维护困难;

  • 早期代码设计较为合理,随着人员不断增加,很多代码重 copy 轻设计,只求完成功能,不考虑维护性拓展性,毫无设计可言;

  • 部分人员 git 不熟练,导致强行覆盖远程分支的情况时有发生,无权限管控;

部分问题示例

  • 全限定名完全一致的类


  • 重复造轮子

三、解决问题方案

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

制定相关规范

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

  • 开发规范

  • DODB 接口规范

  • 开发规范实行计划

  • DODB 版本 tag 命名规范

  • 开发设计模板

  • 提测模板

  • 会议规范

保障规范严格执行

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

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

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

merge 列表界面

merge 详情界面

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

  • 以 tag 追踪生产交付,要求测试交付时一定要有 tag

禁止删除 tag

标签 tag 列表

标签 tag 详情

四、如何对现有代码进行改造

改造原则

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

  • 保证兼容性升级,改造后原有数据和业务不受影响;

  • 对外接口(如 dubbo)原则上不能修改,保证调用方功能正常,特殊情况可沟通配合(如 dubbo 方法重载必须修改);

  • 不需要的代码一律删除,以后需要从历史版本找回,禁止批量注释掉代码;

  • 代码设计要遵循 高内聚低耦合 的原则,保证可重用性、移植性;

  • 目标一致,改造循序渐进,保证充分测试。

部分改造逻辑

  • 对不再使用的代码直接删除,历史可在 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 依赖


  • 对各 module 的功能和命名做了统一规范,对原有代码做统一修改调整


  • 调用 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形式备份 */@Testpublic 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 配置

  • 发布包里有什么

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

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

是否有重复依赖问题

例如 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、各产品线可在统一各依赖版本的基础上,调整构建方式,大幅减小集成包的大小。

改造总结

  • 优化不求一步到位,可逐步进行,目标明确即可;

  • 复杂是一切问题的根源,能用一行代码解决的问题,就不用两行;

  • 一切功能都是靠代码实现的,写好代码很重要,不能把写好代码当成一件小事,只是为了完成所需功能而堆砌代码很简单,但编写清晰易懂且能完成所需功能的代码并不简单;

  • 你永远无法编写出“完美”的代码,要用工具和流程规范来保证这一切,要充分测试;

五、福利放送

云智慧以开源集轻量级、聚合型、智能运维为一体的综合运维管理平台 OMP(Operation Management Platform) ,具备纳管、部署、监控、巡检、自愈、备份、恢复等功能,可为用户提供便捷的运维能力和业务管理,在提高运维人员工作效率的同时,极大提升业务的连续性和安全性。

点击下方地址链接,欢迎大家给 OMP 点赞送 Star,了解更多相关内容~

GitHub 地址: https://github.com/CloudWise-OpenSource/OMP

Gitee 地址:https://gitee.com/CloudWise/OMP

微信扫描识别下方二维码,备注【OMP】加入 AIOps 社区运维管理平台 OMP 开发者交流群,与 OMP 项目 PMC 面对面交流~


用户头像

全栈智能业务运维服务商 2021.03.10 加入

我们秉承Make Digital Online的使命,致力于通过先进的产品技术,为企业数字化转型和提升IT运营效率持续赋能。 https://www.cloudwise.com/

评论

发布
暂无评论
2个动作,让研发效率提升120%,代码减少50%_敏捷开发_云智慧AIOps社区_InfoQ写作平台