Taking over someone else's codebase

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 25th


Florian Mierzejewski

March 25, 2020


  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.”
  11. None
  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?