Taking over someone else's codebase

Android has now been around for quite a while and it's becoming rare to have the chance of writing a new app from scratch in a professional environment. In this talk we'll have a look at problems that may arise while taking on someone else's codebase, what can be done to have an impact from day one and avoid the usual "I don't understand this code" frustration. This talk will include both technical bits as well as more generic advice regarding communicating empathically with other developers and making incremental changes leading to a codebase we feel comfortable and happy with.

Talk given at Berlindroid March 2020 & Android Makers 2020

Transcript

1. Taking over someone else's codebase
2. Florian Mierzejewski Android Engineer @Trade Republic - Berlin, Germany
3. Trade Republic • Europe’s first commission-free mobile broker • Easy, fast and convenient access to capital markets for everyone. • Make stock trading dead simple and commission-free.
4. What is this about? • Avoid frustration • Strategies to take over a codebase • Making it better, leaving it in a better state than we found it
5. Mindset
6. • Starting with a good mindset • Taking everything as a challenge • Learning about new domains
7. –Someone on Hackernews “My #1 rule for existing codebases: Just because you wouldn't have done it the way they did doesn't mean they did it wrong.”
8. –Someone on Hackernews “I think it's developer nature to look at a huge pile of code that someone else wrote and immediately think: This is a pile of crap. I can do better, so the first thing to do is rewrite all of this, my way (which just so happens to be The Right Way).”
9. –Someone on Hackernews “Realise that after 3 years, they have hopefully fixed a lot of bugs and got to a solution that is somewhat mature and better than you can do in a week.”
10. –Someone on Reddit “My number 1 red flag of working with a developer, unless they are very early in their career, is hearing them describe a codebase as awful. Most really are not that bad and are usually just using unfamiliar and less than ideal design patterns and coding practices.”
12. Before starting coding away…
13. Different kinds of taking over • Alone with or without the original developer • With a team that has a clue or no clue about the current codebase
14. Looking at the code • Crash reporting • App reviews • Performance • History of the code
15. • Structure • God classes, base classes • Architecture • Tests • CI setup
16. • Writing down questions while going through the codebase • Dev tools to make life easier • What are the external actors, who are we relying on, how stable are they • Basic security • Deployment process and existing level of automation • High level overview of dependencies • Dependency injection
17. Making use of the codebase owner • Vague understanding of the whole system and then dive into the more non obvious / tricky parts with the original developer • Focusing on the history of the codebase, why are things the way they are? History and context are hard to deduce from code / documentation • Chesterton's fence principle
18. Staying kind • Put yourself in the seat of the original developer, have some empathy • What is this piece of * even doing? - Could you guide me through what this piece of code is doing? • Being understandable, we all have to take those shortcuts during crunch time that we never ever get to revisit later
19. Having an impact
20. Do not • Huge refactoring from the get go • Start writing new code right away • Introduce breaking changes • Play the blame game, it gets you only so far
21. • Understand the purpose of the system, what its users want from it and how they use it to achieve that. • Learn about processes • Get to know the architecture Do
22. Do • Start with a task where existing code need to be changed • Small refactoring tasks / bugs • Get familiar with the language of the domain • Ask for help • Read wiki / documentation
23. Do • Take your time • Communicate your codebase concerns • Take notes on what needs to be looked at / addressed • Find the right level of detail • Create or find a good candidate for a Blueprint
24. Do • Use the debugger • Ask for a time budget on refactoring and share wins to show a positive impact (test coverage up, less dependencies so app smaller, feeling more confident in making changes, app more stable…) • Focus on the worst parts, the rest can always wait, if it isn’t broken don’t fix • There will always be something that needs to be addressed, the codebase is never going to be fully migrated • Expect to write quite some glue between both worlds • Test, Refactor, Repeat
25. Android specifics • Look at what is nowadays considerer deprecated and / or dangerous, AsyncTasks? PostDelayed? Go through @Deprecated warnings • Was there some playing around with things that are experimental / very new • State of modularisation
26. Incremental changes • Extract collaborators from base / god classes • Composition over inheritance • Using ActivityCallbacks • Modularisation (start by creating new modules for features), • Synchronise between platforms
27. Incremental changes • Wrap important domain primitives • Dev tools that make you save time in the long run • Pre-commit hooks • Reduce test execution time • ComponentActivity
28. ComponentActivity • LifecycleObserver • OnBackPressedDispatcher • ActivityResultCaller
29. Use requireX() getActivity().navigateTo(…) VS if (activity "!= null) activity.navigateTo(…) VS activity"?.navigateTo(…) VS requireActivity().navigateTo(…)
30. The Scout Rule
31. • Time to give back so the next person have less of a hard time taking over • How can we make it better so the next one can hit the ground running? • Clear commits, ticket number, explanation if obscure hacks with links • Take note about what was missing while taking over and fill the gaps
32. Zusammenfassung
33. • Taking over is a hell of a challenge, in a good way • Do not approach this as a chore • Do not rewrite the entire codebase • Do take your time • Do make it your own with little incremental changes • Do leave your current codebase as clean as possible
34. Questions?