Re: Will you help me put together a code review checklist?
On Nov 16, 1:37 pm, Ian Collins <ian-n...@hotmail.com> wrote:
On 11/16/10 09:13 AM, James Kanze wrote:
On Nov 15, 12:31 am, Ian Collins<ian-n...@hotmail.com> wrote:
On 11/15/10 01:49 AM, James Kanze wrote:
On Nov 13, 2:49 am, Andrew<marlow.and...@googlemail.com> wrote:
o Code review is a good thing, so we should do more of it. I
reckon pair programming achieves the ideal, where it is being done
*all* the time.
No. Pair programming does not address the issues that code
review addresses. Good code review requires someone from
outside to review the code, not someone who is intimely involved
in it.
True, but coupled with collective code ownership, it does
become a credible alternative to code review.
How? One of the most important aspects of code review is that
at least one of the reviewers is seeing the code for the first
time. And one of the essential elements being reviewed is that
he can easily understand it, uniquely from the code and the
documentation. How does pair programming address this issue?
I wrote "coupled with collective code ownership" deliberately. The more
people who work on the code, the more "fresh eyes" get to read it. As
Francis mentioned else-thread, pairs are not static so the new person
joining the developer working on a particular piece of code will be
seeing it for the first time.
It still sounds a bit random to me.
And I'm not sure what you mean by "collective code ownership".
I'm sure you are:
http://www.extremeprogramming.org/rules/collective.html
All I see there is a bit of verbiage. The first paragraph
describes what has always been the case, at least in industry.
After that, it sort of waffles about chief architect, etc.---a
"chief architect" has very little to do with code, and normally,
doesn't make any unilateral decisions. Roughly speaking, the
article seems to be constructing a strawman to argue against
something, but I'm not too sure what it's arguing against.
Everyone knows, for example, that "Any non-trivial system can
not be held in one person's mind." That's why we insist on
proper documentation. But what this has to do with pair
programming vs. code reviews, I don't see.
Globally considered, pair programming is not cost
efficient (but it can be useful in specific cases, e.g. bringing
a new hire up to speed in your code).
Care to back that up with some real world data?
In what way?
First, clearly, the impact of pair programming will vary
according to the people involved; having someone looking over my
shoulder slows me down most of the time, and reduces quality
(since I'm happy if he understands the code, rather than trying
to make it understandable to anyone who reads it), but I'm
perfectly willing to admit that there are people who work faster
and better in such cases.
A pair will never be looking over your shoulder, he will be working
along side you.
You mean with a second keyboard, both of us entering code into
vim? Or? (When I say "looking over your shoulder", I don't
necessarily mean something passive. Just that he isn't in the
chair directly in front of the keyboard, and he isn't typing.)
Second, of course, the cost per programmer hour is double that
of a single programmer. So unless the effetivity is also
double, it's not cost effective. And while some people might
work faster and better, I've yet to see or hear of anyone who
would work twice as fast.
Work rate isn't the only measure of productivity. Pairs
produce code with fewer defects so they spend less time
debugging and more time writing code.
And that's not what I've seen. At least, not a significant
proportion, enough to justify two people (two salaries) instead
of one. What I've seen is that a good code review (which adds
less than 20% to the total cost) improves things even more.
From my experience on C++ projects, pairs are typically about
1.5 times faster in raw output and produce code with fewer
defects. I wouldn't have maintained the practice for over two
years if I hadn't seen real benefits.
I've seen a couple of places try it, for various reasons, with
no significant difference. Of course, they already had a good
code review procedure, and people were used to writing for
reviews.
One of the things that worries me about pair programming is the
risk that people start counting on the pair to understand,
explaining, orally, as they go along, rather than writing the
information down so that anyone can get to it. Counting on two
people's memory is only marginally better than counting on one
person's memory: knowledge that isn't written down doesn't
exist, as far as the company is concerned, and often even as far
as the people involved are concerned, two or three months later.
(The point of a well run code review, for example, isn't for the
coder to explain the code to the reviewers. If he has to
explain anything in the review process, the code fails the
review.)
--
James Kanze
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]