Possible Duplicate:
How to understand the design and code flow of any product quickly?
I am starting a new job in two weeks and would like to know of any suggestions you can provide.
It's a C++ project, large team (30+), and I'll be the new guy. I know the first thing is to get the source and compile (after getting an overview of how the thing works) but as a coder (developer, I know) any tips?
Don't be afraid to ask team members for advice, they know you're new and haven't worked with it before. It's also quite possible that there's some config thing or a library that needs to be added (or something similar) which isn't in the documentation, and it's better that you figure that out sooner rather than struggling with it for a while before getting it to work.
As a general advice I'd say : "Don't judge too quickly". Newcomers usually tend to think that existing code is "badly designed", "crappy" and could be easily refactored.
It is sometimes the case, but there is often a (good) reason for it to be that way. Don't suggest heavy changes too quickly (unless you're told to). You don't wanna be the "black sheep" of the team.
Read carefully the existing code. You can even print some classes/files that are important and heavily used. If the class hierarchy is complex, you may also try to draw it on a big sheet of paper.
Ask your teammates about things that you don't understand: it's your team, you should help each other. Your employer probably don't expect you to be autonomous before some months so take your time and don't rush things.
And I almost forget: read the existing documentation !
Good luck with your new job ;)
Be humble enough to focus on bug fixing. Find the niggley little things that haven't been fixed in years because no one has the time (often in my life this always seems to be the formatting of dates, for some reason) and fix them. You'll need to find your way around the codebase, get a feel for how everything plugs together and won't be working on anything complicated or mission critical.
Of course your new boss might want you to do something else...
Do exactly what you're starting to do now, just grab information at every stage. Also, if the company has a poor history of recording information, be a help from the outset - record everything you discover - maybe start a wiki that holds all your notes for future people.
I think a good bit of advice that I once heard was that you have two eyes, two ears and only one mouth. It's always best to use them in that ratio.
First, don't try to learn everything as soon as possible; take little steps.
Use your first assignment/task to learn that little bit of code (and related libraries/toolkits if applicable) and go from there.
If they have technical documentation, browse them to get an overview but don't do in details except in places you need to work in.
Use test cases, use "use case" to learn the software from the outside, you might find a lot from that point.
Ask relevant questions to the "owner" of the code.
M.
One helpful approach would be to request examples of projects you'll be assigned or problems you'll address. Then work through it over the next two weeks. That way you'll be able to explore the project in a relatively stress free way, you'll have some good questions for the first day, and impress the bossman.
The way I usually do it, is I make a list of the different things the project can do currently. For example, if it's a website (probably not, in your case, but hear me out), the project can:
So what you need to do, is make a list of the main pieces of functionality. Then open up the compiled project, and walk through the functionality - try to see what's happening in the code as you walk through it. It might be helpful to compile in debug mode.
This will help you learn the general architecture of the project, without having you focus too much on little unimportant things could easily be learnt later.
any information you dig up (e.g. structure of the program, data/process flows, etc...) that was not already explicitly documented - ADD the documentation publicly (ideally the team already has a vehicle for that, like Wiki or somesuch, or at least a shared drive Word document).
The will both help you retain the info when publishing it, help you retrieve it again MUCH faster/easier when you invariable forget it 3 days later, AND get you on a good foot with the team who probably don't have resources/will to do this.
Ask the team for a sample debugging session - nothing teaches you the code layout and flows like debugging - followed up by asking for a minor bug that people know shouldn't be long to find but nobody bothered to fix yet as it's not that important; to get your feet wet. A good team manager will do that anyway, and your showing the initiative will be viewed positively.
Find out your "special" skill that's missing from the team. E.g. you may be a Perl wizard and the team has a bunch of old perl code and no Perl experts to dump it on. Feel free to volunteer. this could be a language that's your strength, or some other skill (web development, design, technical documentation, anything else). this advice might not always be applicable, and obviously doesn't help you as much if there's a homogeneous main code base that you need to learn.
If you're in a junior position, when speaking with a senior-ish manager, find out if there's a technical expert on the team without much management experience who'd be interested in mentoring you. very often, a senior tech guy would be interested in getting "management experience" notch by mentoring someone junior, which means both that he'd be doing this voluntarily - not generating ANY bad will about "wasting his time" - and that he'd do a good job of it since your evaluation of your experience being mentored will be important to that guy's career (this is spoken from experience of having been said tech guy who liked to volunteer to mentor).
Solicit frequent feedback. Explicitly ask the manager whether your observed progress matches his expectations - you want to find out as early as possible if you need to pick it up.
Don't be a total "Stakhanovite" show-off (people really don't like that since it makes the rest of the team look bad if you are at work 20 hours a day), but obviously don't be the last one in/first one out the door in your first couple of years.
To be honest I always hate the 'go and get familiar with the code' instruction you often get at the start. I think that means 'we hired someone because we are too busy. Now, I'm too busy, go away'
Make sure you can build and run the product. After that I usually find that I learn better when I am actually doing somthing, and I only need to learn the part I am doing now. The rest can wait.
When I need to track through code, I use visio to draw simple class diagrams. Whenever I have tried to do it on paper I always run out of space, because I do not know what the important classes are. In Visio (or whatever software you know) you can re-jig the layout. Then you can give the docs to the rest of the team, they will probably thank you for it!
Get intimately familiar with grep and your IDE's search tools. Being able to identify unique strings that are used across classes, etc. will allow you to narrow where you're supposed to be looking to add features or fix bugs. Additionally, you can pull strings from the UI and search for those to find where in the code you need to be looking. Even if they are using an internationalization engine, you can still look up the key associated with that string and use that to search.
Don't be afraid to make changes.
Don't spend time just looking at/stepping through at the code. The only way you know for sure you understand it is if you can make changes. If your change works, you confirm your understanding. If you break the code, you learn too.
Make sure you get feedback. Ideally dayly so you won't waste a day by choosing the wrong direction. Work on one thing at the time, finish it, commit it and then move on.
Get an overview of how the code works from a resident expert and then run through it in the debugger. If your expert will be a buddy while you do this, all the better. Hopefully there are test cases you can use to drive this, if not offer to develop some as part of your rampup. No better way to understand how code works than to watch it in action. Ask lots of questions however dumb they might seem - maybe you spotted something that nobody else has.
Once you have a basic understanding, try to use the code the same way your customers do. That provides a whole other viewpoint than running it in isolation. Black box vs white box, if you like.
On top of all the excellent advice already given, I'd suggest running doxygen on the project (if it doesn't already have a doxygen documentation), and using the output to learn about the structure of the project.
It's like moving to live in another city. You'll get lost in the beginning but with time you'll magically start to feel your away around.
My suggestions are:
Good luck (and go have a drink with your coworkers :)
I think that your newcomer status can also be an opportunity to suggest improvements to the team. People who have been inside the project for a long time have had their reasons to make the software this way, but maybe it is not so relevant any more ; or maybe they missed something that you could consider obvious. It could be hard to find the right words in order to express this without hurting any one, but nonetheless a new opinion on the project can only improve its quality !
A few points, but they fall into two classes.
1) existing knowledge - ask team mates, read documuntation (if any), wikis, comments in code, etc
2) tools - as @static_rtti said, use DoxyGen .. it's my personal first approach - it even works in in un-doxygen-ed code; it can show class structure, proc/fn call-tress, and more. How can that not help? My apporach to legacy/newly entered project code is always to run DoxyGen - and if there are no DoxyGen comments, I add them as I go along.
Maybe a good IDE with code/class browser that let's you jump to the definition of a variable or fn() and usages too.
Maybe try some of thos code-top-flowchart tools? That explains the logic.
But you also want to understand the data, so maybe fire it up in a debugger. If you run Linux, or can emulate your program in Linux using Wine, the I strongly recopmmend DDD. A picture is worth a thousand words - how useful could something like this be?
Pair programming is a great way to get into a new team and a new codebase - ( by this I mean proper pair programming - not sitting watching someone else program).
Also if the new place (as every good place should) has a guide for new starts - make sure you update it with every detail you discover is missing.
I recently experienced a similar situation 3 months ago starting my first job.
Another great way to get familiar with existing code is to run the program in DEBUG mode, set a breakpoint at the application's entry point, and spend some time hitting F11 :)