Coffeehouse Thread

11 posts

Understanding other people's large projects?

Back to Forum: Coffeehouse
  • User profile image
    Manip

    I have trouble getting to grips with other people's projects particularly when they're large. I mean a couple of thousand lines of code isn't a problem... But when it gets into a five or six thousand I just can't get to grips with it, or I haven't yet.

    This is one of those nasty - "The big picture" - problems. And as I'm sure some of you, spending your days working on parts of that picture, would have some insight that could help.

    What do you guys do when introduced to a new project to help you get to grips with it?

  • User profile image
    JohnAskew

    I would create documentation (assuming you have none for the existing system) that perfectly describes what the users believe the current system does (a requirements document, if you will).

    This documentation might start with diagrams illustrating the system at a 50,000 foot view. It may progress to a feature list and further on to details on how the features should work. This depends on how difficult the next step becomes; we may need to go deeper with specifications for the next step.

    After mapping the system (all without looking at code), then open the codebase and attempt to apply the map to the code. You may want to add in-line comments to save your thoughts as you come to grips with the code-base.

    That's how I do it.

  • User profile image
    harumscarum

    Gather all documentation that was created for the project. This is generaly for a brief overview and future reference.

    Get a list of the persons involved in the design and/or development of the project

    The next step is really dependent on how much of the above information you could get. 

    Don't try to understand all of the system at once. Go through each piece of the project as needed. While it is good to have a general overview of the project if you are only working on "Chunk A" you should really only focus your attention there and however it needs to interface with "Chunk B".

    In my experience I am much more efficient when I focus on the smaller pieces rather then "hop scotching" around trying to write code everywhere. I do know the big picture but it is not going to be coded in a day nor understood.

    The one place I would not start is opening the code and just start reading.

  • User profile image
    Rossj

    Skim the docs for an overview and ask for some bugs to fix.  Fixing bugs and ensuring what you fix fits into the project, and doesn't break anything else is a good way to learn the structure of the code.  Only dive into ancillary libs when you need to, but when you do make sure you spend some time understanding what is going on.

    Everyone is different, but that works for me and I've been taking on big projects for a while, the latest is ~50,000 LOC and two databases (with a homebuilt ORM).  I still don't know everyline of code but if you wanted features adding or bugs fixed I'd know where to look.

    I forgot to mention, the debugger is your friend.

  • User profile image
    Lazycoder2

    I've given a presentation at a couple of Code Camps that might help some.

    Forensic Development

    I spend a lot of time tracing a single variable and finding out how it's value changes during the course of a session. I also sniff out any database interactions. In Visual Studio I spend a lot of time right clicking and selecting "Go to definition".

    I look at the code from a functionality POV. I set a break point at the entry point of a given function, say a button event handler or a page_load event, and step through the code until I've completed the function. If give me a better idea of how the code fits together.

  • User profile image
    Minh

    I'd try to understand my piece as well as possible. Look at all the boundaries (what's inside my piece, what's outside) because ultimately, that's what you're responsible for. Sometimes the interface doesn't come across in the documentations, you'll be surprise what you learn about your piece at the water cooler. (yes, new guys have to be more sociable than usual).

    At the same time, I'd try to understand the system as a whole, 'cuz that would help you understand your piece as well. I usually ask for a couple of days (at most a week) where I don't have to be productive and just face-down into the code. I'd document the code -- for self-consumption only, so the docs don't have to be perfect -- don't even have to be good. But the process of documentation IS very useful in learning the system.

    I like charts, so I'd make lotsa call-trees, ER diagrams, etc...

    One thing to remember -- few large code bases follow best practices. Just realize that you'll run into some illogical pieces of code 'cuz some decision were made early & your team has to work with that instead of re-writing the system. Or that, not all of your team members are system architects. So things won't be straight-forward.


    Also, you should freshen up on the underlying technologies used in the system... like User Controls, Session state management, or ASP.net caching if you have the time.


    It ain't easy... but, hey, that's why you're paid the big bucks, right?

  • User profile image
    Detroit Muscle

    I had a 12,000 line assembly language program dropped on my lap at my last job. When I had to modify it I went through it and made state diagrams of all its functions to help me understand it. It was all interupt driven, and I find it easier to gain a quick understanding of interupt driven software than cyclic software.

  • User profile image
    Cybermagell​an

    I'm currently doing this as well...decompiling this AOL Suite .

    Line, upon line, upon line, upon line of XML and JS, and HTML. Basically I have the file open in one Window (Dreamweaver) and notepad so that as I read blocks of code I can add comments to the code for me to refer back to later and in Notepad I'm writing a cheat sheet like Table of Contents so if I want to change anything later I can find it easily.

  • User profile image
    Loadsgood

    Rossj wrote:
    Everyone is different, but that works for me and I've been taking on big projects for a while, the latest is ~50,000 LOC and two databases (with a homebuilt ORM).  I still don't know everyline of code but if you wanted features adding or bugs fixed I'd know where to look.


    What does ORM mean? Oh and that's some good advice you are giving there Smiley



    50,000? Expressionless
    Loadsgood.

  • User profile image
    footballism

    Loadsgood wrote:
    Rossj wrote:Everyone is different, but that works for me and I've been taking on big projects for a while, the latest is ~50,000 LOC and two databases (with a homebuilt ORM).  I still don't know everyline of code but if you wanted features adding or bugs fixed I'd know where to look.


    What does ORM mean? Oh and that's some good advice you are giving there

    I think he means Object Relational Mapping.

    Sheva

  • User profile image
    Rossj

    Yes, ORM means Object Relational Mapping.  And 50k LOC is not a big project, probably one of the smallest I've worked on in the past 5 years.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.