Rewriting the News Plugin Integration Layer: Design, Benefits, and Refactoring Timing

Programmers often face multiple refactoring cycles during their careers. This article uses the news‑plugin integration layer as a concrete example to explore the scope of refactoring, the timing of when to rewrite, and the practical benefits achieved.

Background : The integration layer consists of 23 interfaces and historically suffered from fragmented maintenance, high technical debt, and an outdated framework. A nine‑month “rewrite” project was launched in early 2023 to replace the legacy services with a unified trpc‑go based architecture.

Current Situation Analysis :

Inconsistent service frameworks and old libraries, leading to high maintenance cost.

Non‑unified data pipelines causing duplicated implementations across 10+ information‑flow interfaces.

Difficult test environment setup and poor observability (no tp99/SLO monitoring, limited logging).

Scattered configuration (40+ items across four platforms) and low test coverage (<10%).

Redesign (Rewrite) Highlights :

Unified the 23 interfaces into a single service using the trpc‑go framework.

Integrated the service with the business gateway (smartGW) for traffic control and security plugins.

Standardized 6 web‑side information‑flow formats into one.

Migrated all configurations to a centralized system (七彩石).

Reduced service count from multiple to one, simplifying deployment and dependency management.

Benefits :

Iteration efficiency : Average effort per requirement dropped from 4 person‑days to 2 person‑days (≈50% improvement).

Stability : Interface success rate increased from ~99.89% to >99.99%; SLO violations eliminated.

Cost reduction : CPU usage cut by ~49%, memory by ~20.6%; Redis instances reduced by 91%, saving >20 k CNY/month.

Engineering quality : Codebase size reduced from 102 k LOC to 57.9 k LOC; test coverage rose from <10% to 66.57%; R&D metric score improved from 73.69 to 100.

Observability : Adopted Galilean and Eagle‑Eye monitoring, trace‑colored logs, and centralized log querying, cutting MTTR from ~2 h to ~10 min.

Front‑end gains : JS bundle size reduced by 37% (491 KB → 307 KB), page load time down 10%, and gzip compression saved ~100 ms per request.

When to Refactor :

Code quality degradation (high duplication, complex functions, low testability).

Feature expansion or modification that reveals tight coupling.

Code review or testing feedback indicating low coverage or hard‑to‑test code.

Performance bottlenecks (high latency, inefficient algorithms).

Technology stack or tool upgrades requiring adaptation.

Regular technical audits and quarterly architecture reviews.

Conclusion : The optimal timing for refactoring is “anytime” – the best moment is before technical debt accumulates, but immediate small‑scale refactors are effective once issues are observed.