Technical Debt Governance in the International Delivery Rider H5 Project (DH5)

In the context of rapid business growth, the accumulation of technical debt has become a challenge that development teams cannot ignore. This article systematically explores how to repay technical debt and extract valuable experience from the governance process, using the international delivery rider H5 project (DH5) as a case study.

The DH5 project covers about 80% of the international D‑side business pages (excluding the main order flow). Initially, the three major business modules—operations, governance, and finance—were combined in a single front‑end repository (all‑in‑one‑i18n). As the business expanded, issues such as difficult maintenance, environment conflicts, and poor developer experience emerged.

To address these problems, the project was split into three independent front‑end projects:

op (operations)

govern (governance)

fund (finance)

After the split, several technical debts became apparent:

Business modules : abandoned modules remain in the codebase.

Public components : redundant components were migrated to new projects.

Public methods : multiple implementations of the same functionality, low extensibility, and high maintenance cost.

Debugging tools : incomplete functionality and difficulty switching environments.

The debts are categorized into two main types:

Redundant code

Code defects

Redundant code issues include unused code and duplicated components, while code defect issues cover design flaws (e.g., multiple versions of public methods) and functional flaws (e.g., debugging tool limitations).

Solution: Repay technical debt step by step

The repayment plan consists of:

Delete redundant code, including unused and abandoned business modules.

Resolve code defects by standardizing public methods and improving debugging tools.

For public method standardization, the process is divided into design and implementation phases. The design phase ensures full functionality and future extensibility. The implementation phase focuses on stability and complete replacement of old methods.

The implementation is organized into four stages:

Stage 1 – Verify public method functionality : functional testing and comprehensive documentation.

Stage 2 – Decompose business modules into minimal units : modular design and impact analysis.

Stage 3 – Code and business functional testing : cross‑testing and monitoring.

Stage 4 – Fully replace old public methods : gap analysis and periodic redundant‑code scans.

Debugging tool improvements focus on two problems:

Online debugging difficulty : vConsole is now displayed in both simulation and debug builds for pre and online environments.

Environment switching : a new tab in vConsole enables quick environment switching without external proxy tools.

Results

After the governance effort, the following outcomes were achieved:

Redundant code was removed, reducing system complexity.

Public methods were standardized, eliminating multiple versions and providing clear documentation.

Debugging tools were enhanced, enabling efficient online debugging and seamless environment switching.

Key takeaways

The experience highlighted three essential aspects of technical debt governance:

Redundant code cleanup is the foundation for subsequent improvements.

Public method standardization is the core, improving collaboration and maintainability across teams.

Debugging tool enhancement boosts development and operational efficiency.

Collaboration across small teams proved crucial, and the systematic approach will serve as a reference for future development cycles.