Blibli.com Android Evolution
Article Summary
Cesario Putera from Blibli.com shares a brutally honest story: their Android app went through 4 complete rewrites, each time drowning in technical debt. The fourth attempt? They couldn't afford to stop and rebuild again.
Blibli.com's Android team evolved from a basic lite app to a Titanium hybrid launcher (that just opened a web browser), then to a native app that became unmaintainable with APIs called from Activities, Fragments, and even Dialogs. By the third evolution, they had hardcoded strings, magic numbers, and zero tests across multiple product lines.
Key Takeaways
- Introduced gradual refactoring rules: MVP pattern, 80% test coverage, one feature per package
- Adopted Retrofit2, Dagger2, and RxJava while maintaining active development
- Started with proof of concept on splash screen before tackling complex features
- Created three coexisting codebases: old package, new package, and updated new package
- Team had to rewrite code during bugfix timelines to eliminate technical debt
Blibli.com proved you can escape technical debt hell without stopping feature development by enforcing strict rules for all new code while gradually migrating legacy systems.
About This Article
Blibli.com's third-generation native Android app had serious architectural problems. APIs were called directly from Activities, Fragments, and Dialogs. Business logic got crammed into single classes. Static attributes were scattered throughout the codebase. The Retail, Digital, Hotel, and Train product lines had zero unit tests.
Cesario Putera's team created eight strict rules for all new code. They required separate packages per feature, used the MVP pattern, enforced 80% test coverage, established naming conventions, implemented Dagger2 dependency injection, and used RxJava to reduce boilerplate. Base classes handled styling. They started with the splash screen as a proof-of-concept before rolling out the approach more widely.
The gradual refactoring strategy let the team develop new features and eliminate legacy code at the same time. Three codebases coexisted: the old package, the new package, and an updated version of the new package. Developers rewrote code during bugfix work to systematically remove technical debt without stopping product releases.
