Browse Page Refactoring on Android
Article Summary
Jintin from Carousell reveals how a 3,000+ line Presenter became their team's productivity nightmare. Their solution? A strategic mix of refactoring AND rewriting that didn't require months of downtime.
The Carousell Android team faced a classic tech debt crisis: their Browse page had become a monolithic single Activity with over 10 view types, making every change risky and slow. Instead of choosing between a risky full rewrite or painful incremental refactoring, they took a hybrid approach that delivered immediate wins.
Key Takeaways
- Split monolithic 3,000 line Presenter into feature specific Domain classes
- Used ConcatAdapter to eliminate complex manual section indexing logic
- Deployed feature flags as Plan B when issues hit production
- Broke components small first, then decided rewrite vs refactor per piece
Critical Insight
By splitting large components into smaller pieces first, then evaluating each independently, the team reduced complexity while keeping the business moving forward.
