Taking over someone else's codebase
summary
Starts by check crash reporting and Play Store reviews then inspects commit history, base activities and module layout to judge risk. It names concrete wins: add crash tooling, CI, unit/UI tests, small Gradle tweaks, and remove deprecated APIs. It favors incremental changes—small bug fixes, extract helpers from base classes, introduce modules per feature—and recommends add CI and tests before big refactors, pair programming, a time budget for refactoring, and leaving clear comments for the next owner.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 2:57Whats this talk about
- 4:13Mindset
- 9:45Crush reporting
- 13:55Structure
- 16:57CI setup
- 19:55Understanding the system
- 22:35Staying kind
- 24:42Refactoring
- 26:22Understand the purpose
- 27:08Start small
- 28:44Take your time
- 32:03Use the debugger
- 33:53Android specifics
- 36:37Incremental changes
- 37:58Component activity
- 38:55Boy Scout rule
- 40:00Conclusion
- 40:28Questions
related talks
35mQuickly and Safely Refactoring Legacy Code
50mGuide Refactorings With Behavioral Code Analysis
39mInheriting code, and I don't mean classes
34mCode Review, Forwards and Back
05mRefactor or die
39mArch. App: Prioritizing Technical Debt as if Time and Money Matters
46mGetting the most out of code review
39mEffective Code Review