Taking over someone else's code

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 th开发者_JAVA技巧e 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!

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.

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.

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.

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.

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.

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.

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.

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)

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.

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 get a overview
• I will see many bugs/bad design decisions. Which makes it easier to order and prio them. (instead of picking a irrelevant bug and solving it, I will fix those that really matters)
• I later on have an documentation.
• Documentation will make it easier to justify refactoring/rewrite to the suit's

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.

I've spent most of the last year working on code that I inherited from someone else. There was no documentation and a large amount of what the system was meant to do was not written down anywhere, but in the clients head. The key for me has been to ask as many questions as I could and gather information from every source available. I would recommend compiling your own documentation as you go.

Many people might say don't rewrite code, but that may often be the best way if the code is poorly commented or coded (not self documenting). For code that I struggled with it has often been the best solution.

Another helpful thing to have is some kind of standards document before you begin. The standards doc will help you decipher the code or bring code up to spec and make it easier to understand.