Taking over someone else's codebase

Florian Mierzejewski Android Engineer @Trade Republic - Berlin, Germany

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.

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

Mindset

• Starting with a good mindset • Taking everything as a challenge • Learning about new domains

–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.”

–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).”

–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.”

–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.”

No content

Before starting coding away…

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

Looking at the code • Crash reporting • App reviews • Performance • History of the code

• Structure • God classes, base classes • Architecture • Tests • CI setup

• 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

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

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

Having an impact

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

• 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

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

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

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

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

Incremental changes • Extract collaborators from base / god classes • Composition over inheritance • Using ActivityCallbacks • Modularisation (start by creating new modules for features), • Synchronise between platforms

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

ComponentActivity • LifecycleObserver • OnBackPressedDispatcher • ActivityResultCaller

Use requireX() getActivity().navigateTo(…) VS if (activity "!= null) activity.navigateTo(…) VS activity"?.navigateTo(…) VS requireActivity().navigateTo(…)

The Scout Rule

• 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

Zusammenfassung

• 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

Questions?