Monitoring Android Codebase
Article Summary
Fajar Ulin Nuha from Tokopedia reveals how their 50+ Android engineers manage a codebase that changes so dramatically every single week that assumptions become dangerous. Their solution? Become data-driven developers who measure everything.
Tokopedia's Android team built a complete data infrastructure to monitor their massive codebase with hundreds of metrics. They track module counts, Kotlin adoption, resource sizes, app bundle composition, and performance across constant changes. The goal: make decisions based on facts, not feelings.
Key Takeaways
- Custom Gradle plugins collect codebase metrics automatically on every release
- InfluxDB + Grafana stack replaced Google Sheets for better time-series analysis
- Track module ownership, dependency sizes, and Dynamic Feature impact on downloads
- Automated workflows notify teams via Slack when technical debt appears
- Measure everything: Kotlin percentage, test coverage, code smells per module
By automating codebase monitoring with simple data pipelines (collect, store, visualize), Tokopedia's team answers critical questions like 'Is this module too big?' with numbers instead of guesses.
About This Article
Tokopedia's Android team couldn't tell if their modules were bloated from actual code or from resources. With 50+ engineers constantly changing the codebase, they had no way to track which teams owned the technical debt.
They built custom Gradle plugins that pulled module ownership data from CODEOWNERS files, calculated Kotlin and Java percentages, and queried SonarQube APIs to get test coverage and code quality metrics like bugs and vulnerabilities for each module.
The team could finally see how big their library dependencies were by looking at gradle/caches directories. This let them make real decisions, like converting oversized third-party libraries into Dynamic Feature modules so the app would be smaller for users to download.