3

Possible Duplicate:
How do you dive into large code bases?

I'm about to take on maintenance and enhancements of a fairly large and complex Java EE project with a Javascript front end.

I'm trawling through the code trying to work out how it all hangs together but I wondered if any of you people have come up with a methodology for doing this that works best for you? do you start with the UI and work backwards to the database? Or take discrete 'slices' through the system for particular bits of functionality? Do you take notes?

How do you get up to speed with a new project?

5
  • 1
    Please check the faq. Don't post subjective/discussion topics here.*
    – Mat
    Sep 6, 2011 at 13:06
  • I would run through the Test Team's test to be honest. I would verify and validate what its suppose to do. I would think learn the code betwee the validation input/outputs
    – Ramhound
    Sep 6, 2011 at 13:56
  • I can't find it right now, but I'm pretty sure I've seen this sort of question here before. Sep 6, 2011 at 14:03
  • Start with all of these questions: programmers.stackexchange.com/search?q=legacy+code. At least one has to be close to what you're asking.
    – S.Lott
    Sep 6, 2011 at 14:46
  • The first thing that I do in such circumstances is always to runt he code through stack.nl/~dimitri/doxygen Even code with no DoxyGen comments generates a very useful overview, and understanding of the code structure. Mar 26, 2015 at 15:45

2 Answers 2

1

When faced with a big existing system I keep to the areas I need to go. It depends on the job though.

  • If you are to write a code review. You need to look at everything.
  • If you have to fix bugs. You have to have to get a idea where to look for certain problems.
  • If you have to extend the software. Just keep to your area.

This is talking about > 1 man year projects. I often enough thought I'd seen everything and then discovered that a really big bug was waiting round the corner I hadn't seen.

0

The words large and complex send shivers down my spine... you have 3 options.

1) Cry

2) Stare at code until your eyes go numb.

3) Set up a test environment and start throwing things at it. Go through what's happening line by line and you'll get a general impression quite quickly. A more detailed knowledge can only come with time and bug fixing.

Not the answer you're looking for? Browse other questions tagged or ask your own question.