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