We don't do code reviews here (as a one-man shop RPG-wise, kinda pointless). And most places at which I worked didn't do them either. Not that it ever came up as to why, but my guess would be "Gotta crank out the code; no time."
However, in an earlier incarnation we did what we called a walk-through. Pretty much the same thing, if I catch your drift. Some people seemed to take umbrage, as Alan said. Others found it useful, myself included (I was chief programmer at the time). I think that most of us engaged in it with a positive attitude, but some people do get their egos tied up into their code. Anyway, it served at least a couple of purposes.
First, as a training tool for new programmers it exposed them to what we thought were proper design and coding techniques (top-down design and structured programming) and practical implementations of same.
Second, I hate to mention how many flaws rookie programmers found in my code.
Rarely did anyone flat out criticize (negatively) someone else's program (oh, there was the time some guy turned in one with 2000+ lines of mainline code and GOTO's out the yinyang). And we didn't do a walk-through on every single program. Hard to say what the criteria was now, but obviously the larger and system critical programs under went the drill.
Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: Wednesday, April 08, 2009 8:47 AM
To: Midrange Systems Technical Discussion
Subject: Re: Code review?
Hi Steve
we don't do code review, for multiple reasons, of which the most important
one (in my opinion) is that there is more than one way to skin a cat, and
with "personalized" programming, programmers tend to be ticked off when
someone suggests a different method of obtaining the same result.
What we DO have in place is a group of QA testers
I've found that programmers make the lousiest testers. They tend to test to
prove their changes work. They tend to NOT test to break the program.
The QA testers job is to try and break the program
What this also forces a programmer to do is to document (from a users
perspective) the changes made to the program, and what results should be
expected.
Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
midrange-l-bounces@xxxxxxxxxxxx wrote on 04/08/2009 09:38:56 AM:
Is anyone doing code review on new or modified code before moving it to
production? If so, what is your process? Who participates in the code
review? How ticked off do the programmers get when someone doesn't like
their code? Pros? Cons?
It seems to me that you would have to have shop standards and review the
code versus the shop standard rather than having everyone in the review
tell
how 'they' would've coded the program.
All opinions welcomed.
Thanks,
Steve
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
midrange.com
