18

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

I've been in this situation before and I kind of just poke around the code while really surfing the internet. I care about this job though, and I want to excel. What kinds of things should I look for? How should I go about starting to learn the framework? In my experience, I learn by doing - but clearly they expect something out of me or they wouldn't give me this week to figure out the code.

Community
  • 1
RankWeis
  • 305
  • 1
  • 4
  • What have you done so far? – Atreys Aug 05 '11 at 18:12
  • 28
    Did you ask THEM?? – PhD Aug 05 '11 at 18:12
  • 1
    Start working on test cases to figure out the framework. Get your self ready for when the task comes you shouldn't be spending time looking up the framework docs. – Shef Aug 05 '11 at 18:13
  • 1
    Search help wanted ads for employers that actually need help. –  Aug 05 '11 at 18:17
  • I did ask them - the answers I've been getting are pretty non-committal. And bpeterson: this job is pretty amazing, and I know I'll have a lot to do. It's just a huge company and right now we're in between release cycles, they chose to hire me at this time in order for me to have this opportunity – RankWeis Aug 05 '11 at 18:25
  • 3
    Similar thing happened to me once: maybe it's purely anecdotal but this sort of thing seems to happen more in the summer when more people are on vacation... – FrustratedWithFormsDesigner Aug 05 '11 at 18:27
  • 3
    Totally normal. You're supposed to look at the code, figure out what frameworks they use, make sure you understand them, get a basic familiarity with the code base, maybe come up with some questions if something doesn't make sense, etc. They're giving you time to settle in before bombarding you with work. – Kevin Aug 05 '11 at 18:37
  • Don;t ask us ask your team. – Martin York Aug 05 '11 at 18:53
  • 2
    @bpeterson, he's new and they are apparently busy. –  Aug 05 '11 at 18:58

10 Answers10

17
  • Learn how to use the product.
  • In general most applications use a database. Have a look at the schema. Try to understand how the code uses the data.

If you learn by doing (same as me) then I would say try to find some bugs to fix. If you can get stuck into some low priority bugs it would be an excellent way to gain familiarity with the code.

Andrew Fielden
  • 301
  • 1
  • 4
  • 2
    +1 I was in a similar situation, when something is asked of you and you don't know the system it can be really hard, learning the system and the database can be really helpful – RMT Aug 05 '11 at 18:17
12

I usually start by poking around in the defect tracking system- take a look at where most of the defects seem to be centered and start looking at that code; odds are that you'll be working on that stuff soon anyways so it's a good place to start.

Failing that, you can always ask someone for a 'guided tour' of the project architecture and then look at the areas that are of interest or they mention that are problematic. At the very least you'll get a feel for how things are put together.

If your employer (or you) pays for something that can generate diagrams from code, than I'd generate some based upon the first two sections and get a graphical overview- it might help you get a better picture of how things interrelate.

Dataknife
  • 221
  • 1
  • 3
8

First of all, gather some domain knowledge. What the code is supposed to do and such.

Then, in no particular order

  • poke at it through a debugger.
  • go through the test suites (if there are any)
  • read the documentation on it (if there exists any)
  • read the documentation/look up any third party libraries being used there
  • interact with your team members (this is what we call KT - knowledge transfer)
Sujoy
  • 181
  • 1
  • 4
  • +1 for Domain knowledge. A little can go along way and it massively helps if you know what the users of your system are talking about. – AlexC Aug 05 '11 at 19:17
  • aye, +1 for domain knowledge. It's the most important aspect. – Falcon Aug 05 '11 at 20:27
7

Unless they're completely unreasonable, they won't expect you to hit the ground as an expert next week.

That said, the more you can learn, the more you can impress them. Always good to impress the supervisor.

If you learn by doing, you learn like I do, so I can offer a few recommendations. I assume you have a compiled version of the code. Get familiar with the way the application works, quirks, anything that you think "huh, I don't know how I would do that", any parts that might be cool under the hood. Start there in the code.

Then, if you really want to learn it, start following the flow of data/control through the application. Start at an interesting location, or right at the beginning of user interaction and see how data passes through the system. See what happens at a low level with any user interaction or time based tasks. Take a look and see if there's any points you think that you could optimize or improve, study those points (and if you can, change them and compile them. Don't push a change to management yet if this is a large application, but keep an internal list of things that you can bring up as you get more into the company. Trying to push a change to a system you don't fully understand can have a lot of unexpected sid eeffects, so wait until you fully understand the system.)

However, what it comes down to is: The best thing you can focus on learning fast at a new company is business rules. If there's one central industry you will be working in, learn it. If there's a few, learn all of them. If it's more of a contract to contract business, this will be less applicable.

Anyone can code. But if you understand what the code you're writing does and explain it in explicit business terms, you win.

Sam DeHaan
  • 276
  • 1
  • 4
4

Here's my list of things to find:

  • Build a mental model of the code. What are the main classes? What does the class hierarchy look like?
  • Conventions. How are variables named? Where are tests in the code? Is there are pattern to how the code of a file is structured,e.g. members on top and methods underneath?
  • If there is a bug list or feature list around of things to do, take a couple of them and try to do those tasks. Granted you may not be as fast as someone else but this will be doing something that gets you into the code with a purpose. Low priority bugs may be an example here of little things that are simple to do, left by others as more important things could be done yet it could be useful to show that you aren't afraid to roll up your sleeves and dive right in to get something done. Even if the bug is fixed by someone else, look at the knowledge gained about the code in the process.
  • Watch your co-workers for patterns in interactions. Who are the people that seem more chatty? Who are the ones that seem to be the coding experts? Who has what role? This is something that can be gained if you pay attention and connect the dots. This also isn't necessarily easy but you could consider shadowing someone for another possibility here. "Let me follow Bob for a few days and do as he does," kind of thinking that may or may not go over well. How is the process here?
JB King
  • 16,795
  • 1
  • 40
  • 76
2

I would advise not to just go off and "surf" the net during this time.

Look around the code base, play around with it and attempt to run it (if this is possible), if you can't run it, try figuring out what the code is and what it does. If you find code that interests you, or puzzles you, attempt to find documentation on it, or just ask someone.

Don't be afraid to ask questions to others, possible those that developed the application. They are going to be your coworkers, and know that you are new, so I am sure they would be glad to assist you.

The sooner you learn this stuff, the sooner you will be able to "learn by doing" instead of just looking over code. :)

Summary:

  • Don't just surf the net :)
  • Don't be afraid to ask questions
  • Check out documentation, schema, play around (if possible) with the application
  • The sooner that you finish the initial learning step, the sooner you can start the "doing" step
Rion Williams
  • 131
  • 5
1

This might sound short and not thought out, but it's what one of my co-workers told me to do when I was given a week to poke around in my code base before I really got started:

Open up the solution, compile it, run it, and F11 (step into the next line in the Visual Studio 2010 debugger), until your eyes bleed.

slandau
  • 606
  • 4
  • 13
  • 2
    Makes sense in a way. I would add that sometimes getting the project *even run* on your machine can be a challenge, depending on the previous delopers and completeness of the documentation (if they left some indeed). Of course you should first make sure that the code *is supposed* to run locally.. – Dan Aug 05 '11 at 19:50
1

Here are few steps that I will advise you to do.

  1. If you have some documentation then start reading it and test it by applying it on your code

  2. You need to see how framework / code you have , is working, it is not important to know actually how framework is doing some thing but this step is to have you idea that what it can do using already present API/ functions and how you can put new code/modules like things in it.

  3. Then you need to try to do as much practice of things present in it as you can but with open minded approach. Open minded approach means that you will be doing this for actually understanding purpose , not to just make work done.

  4. Once you have done step 3, then you will have most work done and at this stage if you will have time then it can be good time to check how internally that present code or framework works because during work it is possible that you need to change some of things or fixing some of bugs present in that already present framework.

Once you have done this, then you will be almost ready for work.

Hafiz
  • 315
  • 2
  • 12
1

Screw the Code.. Read read the Docs! oh.. wait...

Morons
  • 14,674
  • 4
  • 37
  • 73
0

I think the best thing to do was try to familiarize yourself with the code. Run it, read through it, understand the program flow, figure out what each part of the code does, etc. This way when you do have your assignment, you will have an understanding of the code and should have a much better idea of how to do whatever they want you to do.

Also, it can't hurt to ask if there is anything in particular that you should focus on while looking at it. They (being your lead or manager) might not have a specific task yet, but they might have an idea and be able to give you a little better focus.