How to understand an existing code-base

Developers usually love working on a “green fields” project: building something brand new. Green fields projects are fun because you have a lot of creative freedom, you can use the latest technologies and because it’s fast and easy when you don’t have to worry about understanding or breaking existing code.

Unfortunately, unless you live in startup-land, developers spend most of their time maintaining existing code. It’s boring, but true. And that’s why I put such an emphasis on writing maintainable code.

Sometimes it’s very difficult to make changes to an existing code-base. Here are four things that I tend to do when I need to understand existing code before changing it:

1. Read the unit tests: if you are lucky enough to have running, passing unit tests, this is a great place to start. It explains the intent of the code, and it helps ensure you don’t break it.
2. Refactor the code: Rename variables and rename methods as you explore the code and start understanding it. Usually I can think of ways to make the code-clearer, or rename confusing variables. Rename-refactoring and extract-method refactorings are relatively low risk and make future maintainers’ lives easier too! Note: I only do this when working with a strongly-typed language and a good refactoring tool.
3. Introduce unit tests: this can be time consuming if there aren’t tests already, but very worth it. I often move a method I’m interested in into it’s own class so that I can introduce Mocks and test the hell out of it. First write tests for existing logic, then for your new logic.
4. Break the code: I enjoy creating a new branch, and then deliberately making big changes to the code to understand how it works. When I’m done… I revert my changes and delete the branch. It’s a experimentation-playground that is very useful when exploring unfamiliar code.

Are there other useful techniques I have not covered here?