How do you approach a new sizeable codebase?

1 points by intermerda ↗ HN
Let's say you inherit a codebase. It could be a new team, company, or a new language that you haven't worked with. What general tips can you give a person to approach this codebase and so they can get familiar with it and start adding features incrementally?

2 comments

[ 2.9 ms ] story [ 15.0 ms ] thread
I personally prefer to just dive in and attempt to get something done. I don't really spend time purely "familiarizing".

It involves a lot of tracing where something happens, just following code, or using logging and debuggers. Once I have found the place I need to be it's usually pretty easy to make minor changes or add similar functionality. Along the way I pick up a lot of info on how things work and where they are located. Over time that adds up.

For new languages/frameworks/libraries docs can be good for the basics and to fill in the gaps.

I generally learn best when trying to get something done, I recognize that might be different for others. A goal helps me focus; instead of learning everything at once, I learn only what I need to achieve my goal, and achieving goals motivates me to keep going.

If it an OOP language I use a tool to reverse the code into UML class diagrams. There are a few of these tools, I use Enterprise Architect. I play with the resulting rat’s nest and I find that tactile exercise necessary to gain an understanding of the relationships between classes. It also serves as a road map for the future