How to read code without knowing archicture

If there's some documents that are already written, I suggest you read them first for you to be familiar on the function of each module on a business/user perspective. If there's none, then it might take time for you to be familiar since you will need to read most of the code, if not all. Personally, I become familiar with it by running the application in debug mode and use break points on some parts that I'm not that familiar. I use different inputs and see what happens. Also, asking questions with other team members can help you become familiar with the system faster.

Experience, my dear, experience and patience.
Most of the code you deal with probably has no architecture at all, it is just the extemporary product of a crazy mind (just like yours or mine).

I agree with OriginalGriff.

Something I do when I have to fix something in a programm I didn't write is to try to simulate the error so I can delimitate a bit the area where I have to focus in. Then I start reading the code and do some schematics on paper about what I read, making relationships, what calls what and so on.

But as he said, there is no gold-formula to do it

There is nothing that can beat a "dry run" through code and reverse engineering to figure out how it works.
Very often, this needs to be done without proper diagrams, so you should go ahead without worrying too much.

Try to figure out where the code jumps to other locations (e.g. a web service, socket etc).
You can almost always debug a local method when you run into issues with it.

First of all understand the software. See if involves any database. If yes, start with it. Go with Top Down (and in between bottom up also) approach.

I like to get an understanding of the existing code around my own changes, I tend to do the follow:


Step through the code in the debugger this gives a good sense of the program flow

Add comments to other peoples code where it appears complex - this helps the thinking process and reminds you later

Draw diagrams UML or block diagrams or whatever, this will help give you a sense of structure (I always like to have a pen and paper, much quicker than visio)

Look at it as a challege not a problem. Focus on what it does do, rather than what it doesn't

I was exactly where you are 7 years ago and I remember how frustrating it would be sometimes when attempting to maintain code written by other programmers. When you are doing new development it's a lot easier because you can write it however you want, but when it's already written you must work within the conventions of how the application was designed and developed. This can be intimidating if the code was poorly written, is suffering from over elegance, or is making use of popular patterns practices and frameworks you are not yet familiar with.

Here are a few things that helped me out with reading code written my others.

1) Get good at debugging. If you have ever heard the old IT expression, grab and end and start pulling, you will find it applies to more than just a nest of Cat5 cable. You can do this with code as well. Even if you are not attempting to fix a bug, place a breakpoint in the place you are trying to understand and step through it. Do it over and over and things may start to click. Also, learn how to use the quickwatch feature, and pin values to the designer to you don't have to mouse over them to see them each time you step through the code. I still use these techniques regularly.

2) Start studying up on Design Patterns. Design patterns in software development were made popular by the Gang of Four, or GOF for short, with their release of the book: Design Patterns, Elements of Reusable Software. This book was released in the 70s I think, and all of the patterns and principles it contains are still not only in use today but still widely regarded as the correct way to write software. Get familiar with these because you will see them all the time in code written by other programmers, you should also know them yourself. The book by the GOF I mentioned above has all it's examples in C++, if you are not familiar with C++, just google GOF design patterns in C#. There are an abundance of articles on the net.

3) Start reading open source code. Go to Github, Codeplex, SourceForge or where ever and start pulling down code and checking it out. Try to look at it with the intent of understanding how it's composed and put together. How to the objects interact. How does it work. After an evening of doing this you may start to see commonalities. This will also greatly increase your over all knowledge of application architecture, which will help when reading code written by others at work. This is a lot easier if you pull and check out projects you find interesting. Also, don't be afraid to email the developer who wrote the code and ask questions about how it works. If they are writing open source code in the first place it's to benefit the development community, and that includes you. I personally, am always pleased to find out someone is checking out my code :)

4) Be leery of other peoples code in general. What I mean by this is just because someone has been programming longer than you, or is in a higher position at your company than you, it does not mean they are a better developer than you. Read the book Code Complete by Steve McConnell, this book is a must read for any new developer and will give you a good understanding of what good code should look like. Then when reading other peoples code, take the things about their implementation that are good and assimilate them into your coding style, but be sure not to pick up their bad habits. This is where being familiar with common best practices will help you. Read the book man.

All in all the fact that your here is a great start. Good luck, and welcome to the industry!

-Adam