Possible Duplicate:
How do you dive into large code bases?
I just joined a new company and started to study one of the their bigger system. For me to be productive, I need to understand the entire system without too much help. Other programers are really busy and dont’ have time to hold my hands.
I used to use brain map to draw a pictorial representation of the system. Any recommendations on what is the right appproach to dissect a big program? It is a .net prgoram by the way.
0
I would start with the documentation of the system: design document, requirements document(s), database schema or possibly a user’s manual. If you are lucky, you will find all of these, but find whatever you can. Read these to get an idea of what the system is supposed to do. Then I would play with the system in a test environment to get a feel for how it works. Once I am comfortable with my understanding of what the system is supposed to do, I would start looking at the code for the simplest subsystem I can find. Maybe a single data entry form or a single analysis algorithm, the key is to find something small enough that you can understand that code completely. Keep repeating this until you have conquered the whole system.
If this is a system of any complexity, this will take a significant amount of time. I would also check with your new manager to see what areas (s)he wants you to focus on. The most important thing is to attack this problem in manageable chunks, you can’t learn it all in one shot.
1
For me to be productive, I need to understand the entire system without too much help. Other programers are really busy and dont’ have time to hold my hands.
You should take this is a danger sign. You might want to look for greener pastures.
There should be a big picture presentation of the system as a whole. Multiple such big picture views. A cartoon for management, a more detailed one for the system architect, a different view for the system integrator. They should have shown you those pictures on day one and walked you through it. Someone should be mentoring you along, pointing you to training materials, tutorials, and documentation; showing you the online resources; checking on your progress; and be available now and then to answer questions you have. You shouldn’t expect the mentor to spend all his/her time with you, but that mentor should be there.
With a large system it might take months, sometimes several months, for you to come up to speed and become a productive asset to the organization — and that’s with a proper system in place. Without a proper system in place, odds are good that nobody understands the system as a whole. The programmers are too busy because they’re busy making a convoluted mess that will eventually come crashing down on them.
4
Personally, I like to dig in and start changing things (learn by doing). Ask for a task and figure out how to get that task done within the system. Don’t be afraid to ask questions – the only stupid questions are the ones you already know the answer to. If you can get it, ask for a code review before checking anything in to the repository (any decent company should do this with new starters anyway).
You won’t learn the whole system off the bat, but once you get comfortable with changing small parts of the system, you’ll find it easier to branch out into other areas and figure out how they work. I don’t know the scale of the system your working with, but I’ve been with my current company for a year, and there’s no way anyone on our team can claim to know how everything works.