Perl Monk, Perl Meditation | |
PerlMonks |
Re: Tips for managing Perl projects?by BrowserUk (Patriarch) |
on Dec 15, 2004 at 22:12 UTC ( [id://415204]=note: print w/replies, xml ) | Need Help?? |
One Code reviewsIt's not a Perl specific thing, but is applicable to every code project outside of the one-man development effort. Code reviews should be quick and painless affairs. More than two reviewers of one peice of code will often lead to arguments between the reviewers; and review time increases with the square of the number of reviewers; so one-on-one is best. The reviewer, reviews the code on their own and makes notes about anything
The reviewer/reviewee get together. The reviewer steps through each of his/her notes explaining: What they didn't understand; Or why they think there is an error; Or what they would have done differently, and why. The reviewee listens, and takes their own notes. At the end, the reviewee gets the opportunity to ask for clarifications, if they are needed. The review is over. If done weekly, the process should take no more than 1/2 hour of meeting time, and a coffee break or two for the reviewer to review latest work. There is
*Updated to correct the ambiguity as pointed out below by itub. I'm not sure that this change reflects what I am trying to say all that well either, but I can't think of a better phrasing. It's about stating reasons without drawing conclusions or offering supporting argument. The desire is to make statements of what and why as simply as possible, and then allow the other party to draw their own conclusions. Of course, the discussion will likely resume later, and become detailed around the water cooler, but the hope is that outside of the formal review procedure, any argument that ensues does not taint the review procedure itself. The code reviews should be scheduled, regularly and not routinely deferable. People should not get into the habit of "cleaning up their code for reviews". Whatever they have at the allotted time is what gets reviewed. This encourages the habit of keeping code fairly clean at all times. Everything you write should be open to review. Ideally, even the standalone quick tests of ideas, as a lot can be learnt from the way people try things out too. This is harder with Perl where so much can be tried out with one-liners and/or perl -de1 and the like. The review process is to give the reviewee an insight into how others read his code, and to benefit from alternative ways of tackling problems. It is up to him to institute any changes in the light of what he learns. Having your best coder review the weakest/least expereinced/newest team members code--and vice versa--is a pretty good way to ensure that your that the weakest get stronger, and the strongest don't get carried away. Re-reviews of code only happen when a developer says his code is unit tested and ready for integration. Examine what is said, not who speaks.
The end of an era!
"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen"Think for yourself!" - Abigail "Time is a poor substitute for thought"--theorbtwo "Efficiency is intelligent laziness." -David Dunham "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
In Section
Seekers of Perl Wisdom
|
|