What are your strategies for diving into a large, complex codebase?

https://news.ycombinator.com/item?id=7179985

by InformalRelief • 12 years ago

15 8 12 years ago

news.ycombinator.com

yawz• 12 years ago

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

osivertsson2• 12 years ago

This really is an excellent book! It has helped me keep my sanity when working on large legacy codebases. Highly recommended.

InformalRelief2• 12 years ago

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

shoo• 12 years ago

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.

osivertsson2• 12 years ago

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.

InformalRelief2• 12 years ago

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.

sdegutis• 12 years ago

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.

SkyMarshal• 12 years ago

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.

What are your strategies for diving into a large, complex codebase?

Related Stories