Re: What is code review? (Java code review)
"www" <www@nospam.com> wrote in message
news:f1vt39$jos$1@news.nems.noaa.gov...
I have found that "code review" or "software testing" is really easy to
get into trouble with the team members, no matter how polite or careful
you are. Why? Because:
Nobody likes his code to be found has "error". It is completely OK for
the systems to be found behave incorrectly one or two years later,
because it is different branch people (or even different company) to
debug and maintain the software. Even they found that bug, nobody will
pay attention to who was the original author of that Java class and that
person should be blamed. But it will be very bad in the same team, when
he just finished his code and tell him that something is not right. He
will say "Thank you" to me. But I will never expect good mood between
him and me.
That's a tricky situation to be in. For what it's worth, where I work,
we feel pretty comfortable about pointing out mistakes to each other. E.g.
"You forgot a null check here", "I think it'd be clearer if you renamed
the method to 'getIntHash', rather than 'getHashInt', etc."
We seem to realize that everyone makes mistakes, so that such
corrections are not so embarassing as to cause tension in the worksplace.
I realize, though, that not everybody is like that, and you don't always
get to choose who your coworkers are.
Pair programming makes this a bit easier, because the feedback is
immediate, and we may console ourselves with "Well, even if he wasn't
around, I probably would have spotted that NullPointer bug eventually
anyway, given a few more seconds of staring at the code...", and the code
can be credited to both of you, so that you both share in its quality (and
its blame). But again, your boss may not be so keen on the idea of pair
programming.
I hope, for your sake, that you're simply underestimating your
coworkers' maturity.
So, no matter what textbook about program testing says, ("non-biased",
"thoroughly", ....), practically, I would just pretend I have reviewed
the code, I have tested it and let the program go. (I will point out one
or two extremely light errors to the author.) The author will get what
he wants, fame or whatever, I get what I want: no enemy and keep my job.
I don't think anyone decides to become a programmer because they think
that'll make them famous. "Microsoft Word" is a very famous application.
Who wrote it? I have no idea. Google is a very famous web application. Who
wrote that? I don't have a clue. In fact, I suspect in both cases it
wasn't one specific person, but a team of people, further diluting the
fame of any one programmer within that team.
I'll also point out that if the boss gives you the task of review a
piece of code, and later on, a bug is found in that piece of code, it will
be both the fault of the original author of that code for writing the bug,
and your fault for not having caught it as reviewer. If this happens once
or twice, it's not a big deal (bugs slip through; that's just how software
development is), but if the code you review is consistently buggy, your
boss may feel you are not very competent in terms of code reviewing, and
that may have adverse effects in the future.
- Oliver