How DODB Improved Development Efficiency with Code Metrics & Refactoring

Introduction

The cloud‑wise digital operations data platform DODB is used as a case study; the R&D team analyzed Java code line count, file count, comment ratio, package size, component dependencies, and other key metrics across historical and new versions to uncover problems in code, project management, and personnel, and to summarize effective methods for improving development efficiency.

Data Comparison

Charts show that the new version reduces comment ratio by nearly 150%, branch count by almost 100%, and improves other metrics.

Code Line Statistics

Past

Now

Code Comment Ratio

Past

Now

Sonar Scan

Past

Now

Data Summary Comparison

Metric

Past

Now

Result

Project module count

12

8

↓33%

Total code lines

174,252

136,484

↓22%

Java code lines

90,310

50,719

↓44%

Java file count

982

583

↓41%

Comment ratio

3%

7%

↑133%

Sonar bugs

92

0

↓100%

External HTTP interfaces

160

100

↓37.5%

External Dubbo interfaces

100

25

↓75%

Package size

226M

170M

↓25%

Project branches

300 (reference)

20

↓93%

Write performance (10K per record)

88W/min

187W/min

↑113%

Component dependencies

ignite, vertx

removed ignite, vertx

Replaced ignite with redis, removed vertx

Micro‑services

1

3

5.3.1 supports independent storage/non‑storage modules

Historical Issues Review

The comparison analysis leads to a review of problems in the historical version across code, project management, and personnel.

Code‑Side Issues

Too many modules, some unused.

Inconsistent package naming causing many fully‑qualified class name collisions and load‑order problems.

Large amount of dead code, e.g., 100 Dubbo interfaces while only 25 are used.

Heavy code duplication and copy‑paste practices.

Reinventing wheels such as HttpClientUtil.

Low comment rate, lack of test cases.

Incomplete migration from Vertx to SpringBoot; both coexist.

New modules require manual creation of boilerplate Controller/Service/DAO code.

Ignite cluster dependency makes services stateful and hard to troubleshoot.

Project‑Management Issues

Lack of strong standards hampers efficient collaboration.

Uncontrolled branch proliferation; many inactive branches.

Branch‑based delivery continues committing after release, making version tracking difficult.

Missing code management standards lead to feature omissions and branch rollbacks.

No code‑review process, causing unresolved conflicts.

Developer Issues

Team members are unfamiliar with large parts of the codebase.

Reluctance to modify or delete code; excessive copy‑paste.

Early reasonable design eroded by rapid feature‑centric coding.

Insufficient Git proficiency leads to forced overwrites of remote branches.

Sample Problems

Fully identical fully‑qualified class names.

Reinvented wheels

Solution Overview

The team established development and interface standards and enforced them through repository permissions and other operations.

Established Standards

Development standards

DODB interface standards

Implementation plan for standards

DODB version tag naming rules

Design templates

Testing templates

Meeting standards

Ensuring Strict Enforcement

Tools and processes guarantee compliance.

Set GitLab permissions to enforce mandatory code review.

Prohibit any direct commits to protected branches; require merge flow.

Merge list view

Merge detail view

Force delete remote branch after completion.

Track production releases with tags; require a tag for every test delivery.

Prohibit tag deletion.

Tag list

Tag details

Refactoring Principles

Do not affect ongoing development or delivery; changes must be isolated.

Ensure compatibility; existing data and business logic remain unaffected.

External interfaces (e.g., Dubbo) should not be altered unless absolutely necessary.

Delete all unnecessary code; never comment out large blocks for later reuse.

Design should follow high cohesion and low coupling.

Proceed incrementally with thorough testing.

Refactoring Logic

Delete unused modules (e.g., bdp‑plugin‑sdk, bdp‑plugin‑zabbix).

Replace duplicated utilities (e.g., HttpClientUtils) with shared tools.

Introduce MyBatis‑Plus for database operations.

<!-- mybatis‑plus dependency -->
<dependency>
  <groupId>com.baomidou</groupId>
  <artifactId>mybatis-plus</artifactId>
  <version>${mybatis‑plus.version}</version>
</dependency>

Merge external Dubbo interfaces bdp‑rpc and bdp‑rpc‑model into bdp‑rpc‑core.

Completely remove Vertx and Ignite dependencies.

Standardize module naming and adjust existing code accordingly.

Module

Function

Package Prefix

bdp‑api

RESTful API and business logic, only depended by bdp‑standalone

com.cloudwise.bdp.api

bdp‑base

Business objects and interface definitions

com.cloudwise.bdp.base

bdp‑commons

Common utilities

com.cloudwise.bdp.commons

bdp‑pipeline

Pipeline data processing

com.cloudwise.bdp.pipeline

bdp‑rpc‑core

RPC interface declarations and entity definitions; must not depend on other modules; external RPC interfaces should be modified cautiously

com.cloudwise.bdp

bdp‑standalone

Main project; entry class DodbServiceApplication

com.cloudwise.bdp.standalone

bdp‑store‑ck

ClickHouse storage implementation

com.cloudwise.bdp.store.ck

bdp‑store‑common

Data layer storage interface declarations

com.cloudwise.bdp.store.common

Use GitLab API to clean up long‑inactive branches.

/**
 * 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 = "*****************";
/**
 * Clean branches: delete merged branches, backup others as tags before deletion
 */
@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<Branch> branches = JSON.parseArray(body, Branch.class);
    // Sort by last commit time ascending
    branches.sort(Comparator.comparingLong(o -> o.getCommit().getCommitted_date().getTime()));
    log.error("Branch count:{}", branches.size());
    branches.forEach(item -> log.info("{}", item));
    // Clean long‑inactive branches
    // ...
}

Package Slimming

Understand how the release package is built by reviewing the assembly.xml configuration.

Identify contents of the package.

Avoid duplicating configuration files inside the 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>

Focus on large lib packages; check for unnecessary or duplicate dependencies (e.g., netty‑all, batik‑all).

Key point: ensure large packages are truly required.

Watch out for duplicate dependencies.

For example, netty‑all aggregates many netty modules; avoid duplicate or mismatched versions.

batik‑all aggregates batik‑* modules; exclude individual sub‑packages.

After analysis, use plugins to trace dependency origins and exclude precisely.

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

Developers should understand the purpose of each dependency and avoid unnecessary packages that increase bundle size and risk.

During code review, pay special attention to changes in pom.xml and prohibit arbitrary dependency additions.

Product lines can standardize dependency versions and adjust build methods to significantly reduce integrated package size.

Refactoring Summary

Optimization is incremental; set clear goals.

Simplicity solves many problems; prefer concise code.

Good code is essential; avoid treating it as a trivial task.

Perfection is unattainable; rely on tools and process standards, and ensure thorough testing.