What are your strategies for diving into a large, complex codebase? - InformalRelief
======
sdegutis
The trick I've used in the past is to start by tackling a single, small,
isolated feature change. After you finish it, start with another one that's
related to this one. Keep doing it until you've covered the whole codebase,
making sure to only do small ones! This trick doesn't work.

------
yawz
Michael Feathers' _" Working Effectively with Legacy Code"_ is a great book
that I would recommend for such situations.

~~~
InformalRelief
Looks interesting. Is this useful if you work with relatively new code (no
Cobol lurking in dark corners)?

~~~
shoo
In the book, Feathers defines legacy code as code without tests.

So it's not really about old languages or old code. It's pretty easy to write
(or inherit) new, difficult to test code, with no tests, in whatever language
you please.

------
SkyMarshal
In a nutshell, find the main/entry method, then walk the tree from there. That
takes you from most general/big picture to most specific/granular and helps in
mapping out the structure.

Obviously for big code bases you can't do it all in a day, but just having a
big picture model in my head when I resume on subsequent days helps fit it all
together.

------
osivertsson
If you are lucky enough that the large and complex codebase has extensive
system-level and unit-tests, then that is where I would start.

Hopefully it is easy to get the codebase up and running so that you can
explore it hands-on and try both happy-path cases and what happens when things
go awry.

Walk through a feature of the code manually or step through it using a
debugger while drawing boxes on how stuff fits together, and what the main
building blocks are.

It will always take time to really understand a new large and complex
codebase. If it is high-quality code it is easier, if you have experience with
similar products it is easier. But to really feel that I grasp the really good
parts and the dark and dangerous corners of a new codebase always takes me
months.

~~~
InformalRelief
I've been using the step-through-with-a-debugger approach, but what I'm
missing are tools for visualisation. Drawing boxes gets way too complicated
way too quickly. I'd like to have something like a UML diagram, but as far as
I know UML can't really be used for that purpose.

