Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
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??


in reply to Tips for managing Perl projects?

One word phrase:

Code reviews

It'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

  • They don't understand.
  • They think is an error.
  • That they would do/have done differently.

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

  • No scoring.
  • No rating.
  • No "you must fix/change/redo".
  • No explainations cross-examinations* of why the reviewer would do it different.
  • No explainations cross-examinations* of why the reviewee did it the way they did.
  • No arguments.
  • No arguments.
  • No recriminations.

*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

Replies are listed 'Best First'.
Re^2: Tips for managing Perl projects?
by itub (Priest) on Dec 15, 2004 at 23:07 UTC
    I'm confused. First you say that the reviewer should explain what he would have done differently and why, and later you say that he shouldn't.

      Your right. That was ambiguously and contradictively phrased. I've updated in an attempt to clarify, though I'm not sure I've suceeded?


      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
        I think it is clear enough now, thanks. I would say that the idea is not to turn the review into a debate.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://415204]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (9)
As of 2024-03-28 09:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found