Approaching understanding a huge project

[somekid413]

About 4 months ago I graduated college with my BS in Computer Engineering. I just started my first real job as a Software Engineer. I have worked in the field on a few internships, but this job presents some interesting challenges.

My main question is this. I just got plopped into this massive project where There will be an enhancement for me to implement(currently in design phases). So for now my manager told me to just go look over the code. Is there any system or process that anyone uses to approach understanding a large program? Also, is this typical first couple week activity for a new employee? Please feel free to share any first week stories.

[wildcard_seven]

If the program is truly massive, it is probably going to be difficult to grasp just by scanning over the code. Can you get a hold of any of the planning materials for the system--use case diagrams, detailed use case specifications, analysis class diagrams, sequence diagrams? If the program was made using object orientated methodology, it surely has a main controller class and several sub-controllers, and all the action flows out from those. The dynamics would be most easily understood from the diagrams I just mentioned.

Whatever happens, report back with how things turned out, or how you decided to proceed--whether anybody on the board gives you some great advice or not. I, for one, would like to see how this works itself out, as I'm hoping to get my own internship/get out in the field soon.

[somekid413]

I found the magic stash of documentation, which is surprisingly good. But still its a tedious process. This product is a combination of about 5 different independent sub systems, each more complex than the last. On the bright side I have about a week or 2 before I get any meaningful work, so hopefully I can become somewhat versed with the product. This is just a new challenge for me, I am trained as a Computer engineer, and have never worked with anything near this in magnitude or complexity.

[MK27]

I get vertiginous when I look at source code for something too big for me to have written myself. I just want it to go away and leave me alone. I'd love to say I browse thru the linux kernel for fun on quiet evenings etc, but I don't. The first time I had to do something like this for a job I was terrified and sort of ashamed.

It worked out fine tho. My approach is to figure out how something works by starting where it starts, then stepping thru it in a debugger (if possible) and by altering the code and seeing what my changes accomplish. Eg, try to break something in particular way then see if it really breaks that way. Add some logging.

You could always, of course, ask some co-workers how they would go about this. They know you are new. If they don't have anything in particular to suggest (eg, "Yeah, this tool and this methodology") you can at least relax knowing in are in approximately the same boat as everyone else (which is better than having someone say in two weeks, "You mean you haven't ___________ with it yet?").

[Epy]

I get vertiginous when I look at source code for something too big for me to have written myself. I just want it to go away and leave me alone. I'd love to say I browse thru the linux kernel for fun on quiet evenings etc, but I don't. The first time I had to do something like this for a job I was terrified and sort of ashamed.

I'm the same way. I'm fast enough at writing new code that I'll just rewrite something from scratch if it's not completely huge...seems like a waste of time, but it's faster than my looking over someone else's spaghetti code.

[wildcard_seven]

^^^^
Yah, I hear you (MK27). It's one of the most dreadful activities to undergo. I haven't used the debugger approach;but, if I'm looking at a crapstorm of code without documentation, the first thing I do is ignore my gut instinct to flee in terror, then I calm down, accept that I'm going to be walking around in a fog, again let my mind go really loose, and just find the smallest part that I can understand and go from there. In the past, I've made the mistake of trying to grasp something in its entirety as quickly as possibly, force-feeding it to myself, and all I end up with is a headache. You've got to accept the limitations of the human mind, and take the easy-does-it approach. It's like being lost in a dark room. Calm down, feel around. Oh, there's a chair. I see, that's a table my leg just bumped into. Slowly you go from complete ignorance to getting an understanding of the room. Nothing beats that feeling when the fog starts to lift and you really start getting the picture, though.

[wildcard_seven]

I'm the same way. I'm fast enough at writing new code that I'll just rewrite something from scratch if it's not completely huge...seems like a waste of time, but it's faster than my looking over someone else's spaghetti code.

lol...you make it sound like a given that you'll be looking at a mad man's code. Is it really that bad out there?

[wildcard_seven]

Although I've done some working with other's code, it's never been on a massive project. To think of it, I suppose a big part of it would be trust--I mean, to save yourself some time and energy. Instead of trying to understand things on a minute level, you could resist your instinct to try to understand every little bit, and just say "ok, I know that accomplishes that. All I need to know is what it does for me, and that it works--not how." and just proceed that way. That is, if things are fairly modular with high cohesion/loose coupling. If things are done in a very procedural fashion, God help you.

[Epy]

lol...you make it sound like a given that you'll be looking at a mad man's code. Is it really that bad out there?

In my profession, sole programmer in a small IT department, I often get exposed to some script-kiddie made POS that isn't even worth looking at.

[brewbuck]

Unless your system is terrible it shouldn't be necessary to understand the whole thing to work on just one part of it. And in any project of more than a couple hundred thousand lines, it's unlikely that any one person anywhere understands every last bit of it. Start by figuring out where in the code you WILL be working, start making some basic changes to it and see what happens.

Also, any big C/C++ project will have some set of core headers and data types which almost everything uses. Figure out where they are and familiarize yourself with those. As for the rest, ignore it.

[VirtualAce]

If you can, run it in the debugger and step through it. This will give you the general flow of things. As well you can look at the headers and do some searching with Find to find out where it is defined, how it is used, and when it is used as well as what public methods it has. You can then search for those public methods and find out where, what, when, and why surrounding their usage. Another good thing to look for is header files prefaced with I which usually means interface headers. Pure headers and no code. This will be implemented somewhere so you can look for classes that derive from these interfaces and look at the impls for more info. As well most classes and interfaces have names that normally (not always) clue you into what they do (classes) and what they support (interfaces).

In dev houses where they have a mainline product that has a massive codebase you can gain admiration quickly by simple learning the codebase as best you can. You will probably uncover things in the code that no one even knows are there and other things that people forgot were there.

[somekid413]

All good advice. The issue is when I say large, I mean massive, so no rewriting the whole thing is possible. there are about 6 modules of which the smallest is about 400,000 lines of code. I have started stepping through it, and obviously, I wont be able to master it any time soon. It is an interesting problem and I'm curious if anyone else has worked on something this big and how they approached it.

[brewbuck]

All good advice. The issue is when I say large, I mean massive, so no rewriting the whole thing is possible. there are about 6 modules of which the smallest is about 400,000 lines of code. I have started stepping through it, and obviously, I wont be able to master it any time soon. It is an interesting problem and I'm curious if anyone else has worked on something this big and how they approached it.

I was the team lead for an entire line of products, total codebase weighed in at over a million lines. I worked on that code for 9 years and never understood it all. Nobody did. There is no "mastering" a million line codebase even if you are a genius. If it's well written, you won't need to know it all anyway.

Any design that big which isn't collapsing under its own weight probably has a pattern to it. I can't even begin to guess what the pattern is without seeing the code, every project evolves differently. But if you can start to understand the pattern, the philosophies that drove the development, you can start to understand.

Also, become familiar with the timeline of "disasters" that have befallen the codebase. Every project that's been around a while will have been through some rough times. The rough times have a huge influence on the design, because people hate getting burned. Ask somebody for a narrative history of the code, the releases it has gone through, funny stories they have to tell about it. There's critical information to be had in there.

[MK27]

Ask somebody for a narrative history of the code, the releases it has gone through, funny stories they have to tell about it. There's critical information to be had in there.

Projects that size merit a codesinger -- an oral historian who has memorized an ever-evolving narrative in rhyming couplets, which can be recited in several consecutive evenings set to music.