How We Refactored a 66k‑Line Home Page to Cut Feature Delivery from Days to Hours

Background

The original homepage service was a monolithic Java application named FeedBase with a single main entry point and roughly 66 000 lines of code. Key pain points were:

Learning the codebase required at least three months.

Adding a new feed type took about seven workdays.

Introducing a new tab required roughly three weeks.

No end‑to‑end request tracing; production bugs were hard to locate.

95th‑percentile server response time was 870 ms.

Portions of the logic were unmaintained.

Guiding Principles for Refactor

Direction: Define a target architecture that matches current business scenarios rather than an idealised, immutable design.

Standards: Refactoring should improve engineering efficiency, collaboration and business suitability, not merely showcase fancy patterns.

Methodology: Align developers’ skill levels with concrete, bounded tasks.

Continuous Improvement: Encourage proactive design, safe experimentation and shared ownership.

Refactoring Process

1. Define Direction and Rationale

The team asked why a refactor was needed, identified “rot” in the existing code (tight coupling, hidden hacks, lack of observability) and agreed that the new architecture must be adaptable to evolving feed business.

2. Adopt Module‑Based Development

Instead of a pure interface‑first approach, each developer was assigned ownership of a single module (e.g., filter, serialization, session). Interaction patterns were formalised as:

Call‑inbound: Other modules call this module. Refactor the module and adjust callers as needed.

Call‑outbound: This module calls others. Preserve the original interface; if the callee is not ready, insert a temporary adapter that forwards calls to the legacy implementation.

This pattern avoids deadlocks caused by undefined interfaces and enables gradual rollout. An example is the FeedItem serialization change: the new format was introduced while the session module still expected the old protocol; a thin adapter translated the new format to the old one until the session module was updated.

3. Small Incremental Changes ("Small‑step‑fast‑run")

Developers worked on isolated functionalities, making tiny, low‑risk modifications. In the filter module, the first step was to remove complex if/else hacks, extract basic operators into reusable functions, and then recombine them. This approach:

Minimised regression risk (near‑zero).

Required little domain knowledge, reducing learning cost.

Provided immediate insight into legacy logic.

Subsequent steps added temporary adapters or refactored additional operators, always keeping the change set small enough to be reviewed and deployed quickly.

Results After 2.5 Months of Refactor

Time to add a new feed type reduced from 7 days to 2 days (projected 1 day after phase 2).

New tab rollout shortened from ~2 weeks to 3 days.

Implementation of a new promotion slot dropped from 1 day to 1 hour.

Learning cost for the homepage architecture fell from ~3 weeks to 3‑5 days.

Real‑time feedback loop for recall algorithms became available.

Full‑link log tracing was introduced, enabling rapid bug localisation.

Generalised card release allowed new feed types to be launched without client version updates.

Integration with the new AB testing platform (including Runtime) enabled dynamic online experiment analysis.

Overall, the refactor transformed the monolithic homepage into a set of loosely coupled services with improved observability, lower latency, and a dramatically reduced onboarding curve for engineers.