I think this is a fairly common and challenging topic for anyone that has ever i
ID: 659994 • Letter: I
Question
I think this is a fairly common and challenging topic for anyone that has ever inherited code from another programmer or team. I can think of two common scenarios in my professional career that I've run into; diving into an open source project, and strictly inheriting the code of an individual's project.
I'm coming up on the latter and will be inheriting a project created by an individual, and while thinking about how to best approach this, I figured I would ask for the intelligence of p.se so I can learn from your experiences.
When Magento (large scale eCommerce application) came out, I was really lost in the Zend framework. There was little documentation out during alpha, so it was hard to use the community resources. I ended up using grep a lot and back tracing methods to get a firm understanding of what it does. By doing that, I eventually learned more about the application design, although it did take a little while.
What is your approach when you're up against a project that has little documentation? I feel like it is almost finishing the painting of someone else, which is always an interesting task.
Explanation / Answer
Well, there has to be written down somewhere the intent of what the program or application is supposed to do. From there, you can get an insight into what the possible inputs and outputs of the program might be. When there is a problem, set a breakpoint and trace through the program. This will give you great insight into the overall program flow and if it is broken. I assumed a heaping pile of garbage four years ago. It is a POS application that cashier's use to process parking tickets. Four years later, it is working pretty well with some bugs still found here and there, but definitely easier to work with. Maybe it is easier to work with now because I am very familiar with the overall structure - I don't know. There probably are some comments to help guide you but maybe not enough to figure out why. That's where your debugger and IDE come into play in helping you inspect the value of member variables and examine the program in action.
That's the only advice I can give from someone who was in this very same boat four years ago.