Resources for learning how to better read code

Question

I recently inherited a large codebase and am having to read it. The thing is, I've usually been the dev starting a project. As a result, I don't have a lot of experience reading code.

My reaction to having to read a lot of code is, well, umm to rewrite it. But I need to bring myself up to speed quickly and build on top of an existing system.

Do other people have techniques they've learned to absorb a code base? At this point, I'm just reading through the code. I've tried generating UML diagrams using UModel. They're so big they won't print cleanly and when I zoom in, I really do lose the perspective of seeing all the relationships.

How have other people dealt with this problem?

Opuntia

Answer 1

Wow - I literally just finished listening to a podcast on reading code!!!

http://www.pluralsight-training.net/community/blogs/pluralcast/archive/2010/03/01/pluralcast-10-reading-code-with-alan-stevens.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+pluralcast+%28Pluralcast+by+Pluralsight%29

I would recommend listening to this. One interesting point that was made that I found radical and may be something you could try (I know I'm going to!). Download the entire source code base. Start editing and refactoring the code then...throw that version away!!! I think with all the demands that we have with deadlines that doing this would not even occur to most developers.

I am in a similar position to you in my own work and I have found the following has worked for me: - Write test cases on existing code. To be able to write the test case you need to be able to understand the cde base. - If it is available, look at the bug\issues that have been documented through the life cycle of the product and see how they were resolved. - Try and refactor some of the code - you'll probably break it, but that's fine you can throw it away and start again. By decomposing the code into smaller problems you'll understand it bettter

You don't need to make drastic changes when refactoring though. When your reading the code and you understand something, rename the variable or the method names so the better reflect the problem the are trying to solve.

Oh and if you can, please get a copy of Working Effectively with Legacy Code by Michael C. Feathers - I think you'll find it invaluable in your situation.

Good luck!

Valentin

This podcast really sux compared to my suggestion imho. It is very vague and based rather on literature than real source code practices. – Selry

I'm a big fan of SE radio but I think most people who listen to teckie podcasts are aware of it now and listen regularly - I only came accross this podcast recently so I thought I'd share – Valentin

Answer 2

In general I start at the entry point of the code (main function, plugin hook, etc) and work through the basic execution flow. If its a decent code base it should be broken up into decent size chunks, and you can then go through and figure out what each chunk of the code is responsible for. Looking back at when in the execution flow of the system its called.

For the package/module/class exploration I use whatever doxygen will generate once its been run over the sources. It generates some nice class relation diagrams, inheritance hierarchies and file dependencies graphs. The benefit of these is they are each focused on a single class and how it ties it with its neighbors, siblings and parents, so the graphs are usually of manageable size and easy to understand.

As you understand what different, classes, functions and sub-systems do I like to add comments to fill what sounds like obviously missing documentation. This helps you when you re-read through the code the second time.

Electrician

Answer 3

I would recommend another podcast and resources: SE-Radion episode on Software Archeology

Fasten

Answer 4

This article provides a guideline

• Visualization: a visual representation of the application's design.

• Design Violations: an understanding of the health of the object model.

• Style Violations: an understanding of the state the code is currently in.

• Business Logic Review: the ability to test the existing source.

• Performance Review: where are the bottlenecks in the source code?

• Documentation: does the code have adequate documentation for people to understand what they're working on?

Rawdin