I am taking over someone elses code. What are some good ways to learn what that programmer did as quickly as possible? I have been running it, stepping through it and looking at the callstack. What else can I do?
Sorry I forgot to mention, but there is little documentation and I have been trying to fix simple problems. Thanks!
Set logging to observe in what sequence things are happening.
Read here: Hired as a developer to maintain and update current code base, no docs!
Fix a simple problem in it.
Edit: Then fix bigger problems, and start writing documentation and unit tests, of the areas you understand. Build on those areas, and one day you might understand the whole system.
Documentation? Reading the code itself, without running in the debugger?
Other than that, you're doing what I would do.
I find that I wont learn the code completely until I start fixing bugs / modifying it. If the original programmer is still there, then discussing the changes before implementing them would help.
Usually the best way is to start working on the code fixing small bugs. The more true time you spend with it is the only way to learn the code base. There is no magic way to learn a code base. It will take weeks, months or possibly years depending on the complexity. However for most generic business systems a ramp up time is about 6 months of code knowledge and 6 months separate of industry knowledge to truly understand it all.
Logging is good to see what the code does.
If you have a versioning system you could go and see what changes di the programmer do to what pieces of code, browse some history.
I find it useful sometimes to somehow try to understand the programmers code style, this helps me understand how could he think about a problem and solve it.
Start writing unit tests, as that will get you using his classes/methods, and you will do two things, learn it, and either find bugs or have tools ready in case bugs appear.
The first thing I'd do is take a look at the simplest dialog box and its code, mostly to analyze the coding style and look at how the developer prefers to arrange the code.
Once you know the coding style, and roughly where everything will exist in the file (or if things are put in randomly -- even that is helpful to know), it will be easier to go through everything else.
There's no silver bullet in how can you understand someone else's code quickly. Specially if it's full of hacks and no documentation is avaiable.
You should try to understand the class structure, and execute the normal flow of the software, with a debugger help.
Don't jump too much code sections "oh, I think I know what this section does". No, you don't. You would be surprised of what "innovation" we may find in code.
Talk to the users of the other person's code if you can (either end-users or other developers that had to work with his code). That will give you a sense of the quality of the other persons code - was it released with just a few bugs or did it take 6 months of revisions to get it right? Was the developer careful about making a nicely polished application or was it a mess? That should give you some idea of whether you need to just tune-up the code a bit or start replacing large chunks of it.
I like starting to add tests to the methods of the code, if they are not already there. Figuring out how to cover the code gives you a lot of insight into the codepaths, what the expected output should be, etc...
Everything everyone else has said is accurate in learning what the coder has done.
One other way of looking at it though is to learn the program itself. Play with the application in depth like a user would and understand what the program itself does. Once you understand the final system thoroughly it will be a lot easier to work out how and why it was written.
It wouldn't hurt to document what you learn about classes, functions, etc. as well, just so the next guy (or another person who gets hired to work on the same stuff).
Also, when I've done this before, I've found it best to use the program quite a bit before trying to understand the code. May sound obvious, but more of what you see will make sense after that. Unit testing, as other people have suggested, may also help in the same way. (Helpful when you feel confident enough to refactor, as well.)
One thing that helps me learn systems faster is writing the documentation myself.
I think knowing what the code does, the problem it was written to solve at an high level is a good start. With that one can then mentally, at an high level too try to envision how such a problem might be solved with the type tool used.
From then, looking through the code will take on some meaning, and it will help in making it possible to follow the thought of the original developer. In addition, you will quickly spot when you are getting lost.
I also believe the code should document itself as my experience most time is a documentation outside of the code most times is out of sync with the code and could be misleading. So a few comments here and there, class headers, method comment should help too.
First time I inherit another person's code, I had migraine after two days, i was a nightmare.
So have fun.
The first place I start is the database.
In my experience, understanding the datamodel is key to giving you context when you go through the code. (this assumes the data model is not a generic key-value generic entity table)
Talk to the original developer, because:
If the developer is not available, then you've got to find as many substitutes as possible.
And my last tip: try not to re-invent the wheel. If there is code somewhere you can re-use, then figuring out how to re-use it will provide valuable insight.