Like Tree10Likes
  • 1 Post By wildcard_seven
  • 4 Post By MK27
  • 1 Post By wildcard_seven
  • 1 Post By brewbuck
  • 3 Post By MK27

Approaching understanding a huge project

This is a discussion on Approaching understanding a huge project within the Tech Board forums, part of the Community Boards category; About 4 months ago I graduated college with my BS in Computer Engineering. I just started my first real job ...

  1. #1
    Registered User
    Join Date
    Dec 2009
    Posts
    41

    Approaching understanding a huge project

    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.

  2. #2
    Registered User
    Join Date
    Jul 2010
    Posts
    86
    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.
    stahta01 likes this.
    I made a pair of "Braille Gloves" which have 6 vibration motors in six finger tips and vibrate in the relevant patterns. I have used this to read stuff while out walking. Given there is a fairly well defined programmer-oriented Braille encoding I should imagine it would work in this situation. Diagrams could be a pain still.

    Note: I am not blind but have learnt Braille fairly easily so for me it works quite well

    Disclaimer: I haven't tried this while driving yet...

  3. #3
    Registered User
    Join Date
    Dec 2009
    Posts
    41
    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.

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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?").
    Last edited by MK27; 01-17-2012 at 09:16 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  5. #5
    Epy
    Epy is offline
    Fortran lover Epy's Avatar
    Join Date
    Sep 2009
    Location
    California, USA
    Posts
    977
    Quote Originally Posted by MK27 View Post
    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.

  6. #6
    Registered User
    Join Date
    Jul 2010
    Posts
    86
    ^^^^
    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.
    Neo1 likes this.
    I made a pair of "Braille Gloves" which have 6 vibration motors in six finger tips and vibrate in the relevant patterns. I have used this to read stuff while out walking. Given there is a fairly well defined programmer-oriented Braille encoding I should imagine it would work in this situation. Diagrams could be a pain still.

    Note: I am not blind but have learnt Braille fairly easily so for me it works quite well

    Disclaimer: I haven't tried this while driving yet...

  7. #7
    Registered User
    Join Date
    Jul 2010
    Posts
    86
    Quote Originally Posted by Epy View Post
    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?
    I made a pair of "Braille Gloves" which have 6 vibration motors in six finger tips and vibrate in the relevant patterns. I have used this to read stuff while out walking. Given there is a fairly well defined programmer-oriented Braille encoding I should imagine it would work in this situation. Diagrams could be a pain still.

    Note: I am not blind but have learnt Braille fairly easily so for me it works quite well

    Disclaimer: I haven't tried this while driving yet...

  8. #8
    Registered User
    Join Date
    Jul 2010
    Posts
    86
    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.
    I made a pair of "Braille Gloves" which have 6 vibration motors in six finger tips and vibrate in the relevant patterns. I have used this to read stuff while out walking. Given there is a fairly well defined programmer-oriented Braille encoding I should imagine it would work in this situation. Diagrams could be a pain still.

    Note: I am not blind but have learnt Braille fairly easily so for me it works quite well

    Disclaimer: I haven't tried this while driving yet...

  9. #9
    Epy
    Epy is offline
    Fortran lover Epy's Avatar
    Join Date
    Sep 2009
    Location
    California, USA
    Posts
    977
    Quote Originally Posted by wildcard_seven View Post
    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.

  10. #10
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    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.
    Epy likes this.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #11
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    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.

  12. #12
    Registered User
    Join Date
    Dec 2009
    Posts
    41
    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.

  13. #13
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Quote Originally Posted by somekid413 View Post
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  14. #14
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by brewbuck View Post
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Need HUGE help
    By zbred in forum C Programming
    Replies: 19
    Last Post: 04-10-2011, 04:19 PM
  2. [C++0x] Comments to the FCD approaching deadline
    By Mario F. in forum General Discussions
    Replies: 0
    Last Post: 07-19-2010, 07:53 AM
  3. Huge Project...
    By cpharry in forum Projects and Job Recruitment
    Replies: 4
    Last Post: 08-03-2008, 02:49 AM
  4. Help with understanding project
    By Turtal in forum C Programming
    Replies: 5
    Last Post: 12-05-2006, 06:36 PM
  5. Approaching C
    By olbas in forum C Programming
    Replies: 11
    Last Post: 03-13-2004, 09:41 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21