Re: What is code review? (Java code review)
Patricia Shanahan wrote On 05/10/07 14:37,:
Sherm Pendley wrote:
www <www@nospam.com> writes:
I feel this is crazy!!! Since the reviewer has to "read" the original
code author's mind and make sure the code does what the author wants
and no hidden surprises!
If ESP is required to divine the code's purpose, that's already the first
sign of a problem. There should be:
a. A written specification
b. Unit tests
c. Comments within the code itself
d. The non-comment code
Essentially, all code should be treated as communication to two
audiences with very different needs. The compiler just cares that an
identifier follows the language syntax, but "xyzzy" is just as good as
"columnNumber". The other audience is programmers, including the
author's own future self, three years later after writing a few thousand
lines more on other projects.
In addition to identifier selection, there are often multiple ways of
coding something, some of which make intent and meaning clearer than others.
Looking on the optimistic side, suppose the code is really well written,
and would be easy for another programmer to maintain. The code review is
the chance for the boss to get the good news.
Another benefit of code review is the exchange of
ideas between author(s) and reviewer(s). "What you've
got will work, but if you used two BitSets and a HashMap
you could avoid most of the database queries." "This is
fine, but it would be easier to internationalize (should
we ever decide to) if it were refactored thusly: ..."
Or even "Hey, this is slick. Y'know, in a review
last week we saw some code where Zaphod solved a problem
a lot like this one, but this is better. If you'd make
changes X,Y,Z we could use your code in his project, too."
The main thing is to approach a review -- in either
role! -- with a peculiar mixture of pride and humility,
not with an amalgam of arrogance and apprehension.
--
Eric.Sosman@sun.com