Game Development Reference
In-Depth Information
Each Change Gets a Bug Number
At the end of the project, it
s a good idea, although somewhat draconian, to
convince the team to attach an approved bug number with every change
made to the code. This measure might seem extreme, but I
'
'
ve seen changes
into the code base at the last minute without any involvement from
the rest of the team. The decision to do that shouldn
snuck
t be made by a
programmer at 3 a.m. on Sunday morning. Also, if you come across a
change in code that has a bug number attached, it is a trivial matter to load
up the bug to see what was going wrong and even how the bug can be
reproduced if you have to try an alternate fix.
'
There are plenty of software companies that employ some form of code review in their
process. The terms
code review
and computer game development don ' tseemto
belong in the same universe,
let alone the same book. This false impression comes
from programmers who don
t understand how a good code review process can turn a
loose collection of individual programmers into a well-oiled team of coding machines.
When most programmers think of code reviews, they picture themselves standing in
front of a bunch of people who laugh at every line of code they present. They think it
will cramp their special programming style. Worst of all, they fear that a bad code
review will kill their chances at a lead position or a raise.
I
'
ve been working with code reviews in a very informal sense for years, and while it
probably won
'
t stand up to NASA standards, I think it performs well in creative soft-
ware, especially games. It turns out there are two primary points of process that make
code reviews for games work well: who initiates the review and who performs the
review.
The person who writes the code that needs reviewing should actually initiate the
review. This has a few beneficial side effects. First, the code will definitely be ready
to review, since the person needing it won
'
'
t ask otherwise. Programmers hate sur-
prises of the
kind.
Because the code is ready, the programmer will be in a great state of mind to explain
it. After all, they should take a little pride in their work, right? Even programmers are
capable of craftsmanship, and there
someone just walked in my office and wants to see my code
s not nearly enough opportunity to show it off. A
code review should be one of those opportunities.
The person performing the review isn
'
'
t the person you think it should be. Most of
you reading this would probably say,
the lead programmer.
This is especially true
if you are the lead programmer. Well, you
re wrong. Any programmer on the team
should be able to perform a code review. Something that is a lot of fun is to have a
junior programmer perform code reviews on the lead programmer
'
'
s code. It
'
s a great
 
Search WWH ::




Custom Search