4

I'm new to VC++, and so am not very familiar with COM, ActiveX, IDL etc. When I mentioned this to my tech-lead, he assigned me the task of doing the code review of files he felt were important, in terms of the code that I'll soon be working with.
The actual code-base is approx. 10000 files.

I'm a bit skeptical that doing a code review can help in understanding VC++ (I've already worked with C++ on Linux extensively for 2 years and have plenty of experience in Actionscript, Processing and many other languages).

Since the code yet has to be built and run on my system (I'd prefer putting breakpoints and finding the code-flow), my tech-lead gave me the code review work. Is there a better way?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Nav
  • 1,173
  • 1
  • 11
  • 23

2 Answers2

2

This is a good scenario--it looks like you are being granted an opportunity to learn--be grateful that you are not being asked to code anything straightaway.

Advice:

  1. Establish what version of DirectX you are working against.
  2. Determine what parts of the system use "managed" or "unmanaged code".
  3. Become familiar with the concepts of COM programming, especially with .NET interoperation with COM objects.
  4. Use Visio or other diagramming tools to reverse engineer the code into diagrams, such as Sequence Diagrams. Some versions of Visual Studio provide this functionality.

  5. If using .NET, a good exercise in understanding the build order is to analyse the *.*proj files--these can be built at the command line using msbuild.exe, but it is even easier to configure the build commands using NAnt to call msbuild.exe, like this:

    <exec program="${framework::get-framework-directory(framework::get-target-framework())}\msbuild.exe" commandline="${solution.file} /t:Rebuild /p:Configuration=${build.configuration} /p:TrackFileAccess=${build.trackfileaccess} /v:detailed" workingdir="."/>

Figuring out how to build the system without having to depend on the Visual Studio user interface will help you to become more deeply familiar with the system's dependencies, and will likely impress your team lead.

mikequentel
  • 256
  • 1
  • 3
1

In general, yes, code review is a good way to learn a code base.

As described, maybe, code review is a way to learn VC++.

I know that's wishy-washy, but it truly depends on the goal of the code review and how it's carried out. If you're being used as a QA step, independently doing code review at your work station to distract you while your dev system is set up, then you're going to have a hard time learning anything. You can certainly turn it into a learning experience with the right mindset (taking notes, recording questions), but it's an overwhelming way to start. You have no context, and in this environment, no way to even test your assumptions. This is not dissimilar to the age-old trope of putting new team members on low priority bug fixes. You'll learn enough out of necessity to fix that bug, but you won't have the big picture.

If the goal of the code review is to get you familiar with the system, then it should be carried out as part of a group exercise, with projectors and discussion. A code review is a great way to focus communication and the instant feedback you can get can accelerate your learning curve. You'll have an opportunity to point out confusing parts and get answers in context of the code you'll be working on.

Edit:
Given your constraints, I have two more suggestions. If you can setup a machine that will run VC++ (but not necessarily your project's full dev environment), you could try prototyping concepts as you come across them in the code. So, discover a new technology in your code reading, fire up Visual Studio, find an example online and get it running, then adapt the example (as much as possible) to match the code you're reading.

The other suggestion is to approach it as described in this other answer. This is a new system, you don't know anything about it and are encouraged not to trouble others. You can still do some measure of "debugging" via breakpoints, you just have to do it on paper. This will feel painful (it is), but it will improve your code reading skills and will give you another tool to use when firing up a debugger isn't optimal.

Community
  • 1
Steve Jackson
  • 3,595
  • 1
  • 20
  • 27
  • I'm supposed to convert a lot of existing tightly coupled DirectX and GDI calls into a separate black-box kind of graphics engine which works on a popular rendering library. It's a complete concept change, so the tech-lead initially wanted me to see the code, the interfaces and figure out how to modify it. I tried, ended up lost and reported it to him. That's why he's suggested the code-review. Although as you said, it's gonna be hard without communication from the team and without good documentation. What did you mean by "QA step"? I'm taking the whole thing positively though. – Nav Oct 21 '11 at 13:23
  • @Nav: I meant code review as a Quality Assurance step (looking for defects), as opposed to reviewing code to get you up to speed. Some organizations do "offline" code review, where it's like editing a book, others do "conference room" code review with projectors, whiteboards, etc, and still others use tools to do a hybrid online approach. If the normal code review process is a "conference room" one like I described, then it's a natural fit to bring a new team member up to speed. – Steve Jackson Oct 21 '11 at 13:36