radiantmatrix has asked for the wisdom of the Perl Monks concerning the following question:
I think of myself as a moderately good developer. I have a reasonable amount of experience, I know about common patterns, I reuse code when possible, I try to follow good development practice.
I use test-driven development, I religiously use a revision control systsem. I use Devel::Cover to check that my tests cover 100% of the code I write. Likewise, I ensure that I have good Pod::Coverage.
I've done informal code reviews before -- at many of my clients, my co-workers disdained code review, so I found ways to do it "on the sly": "Hey, I'm not sure about this module, would you look at it with me?"
Now, though, I have an opportunity to do more structured and formal code review. I don't want to bury the process in formality and paperwork, but it is important that I can point a manager at documentation and say "yep, I really did code reviews, here's the proof".
Can the members of the Monestary suggest:
- Ground rules for having useful code reviews
- Ideas for what kinds of documentation I should have to prove they've been done
- Any other information about conducting semi-formal code reviews in a way that's really useful for developing (esp. in Perl).
I'd certainly benefit from the experience of my esteemed brothers and sisters.
Ramblings and references
“A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort.” — Herm Albright
I haven't found a problem yet that can't be solved by a well-placed trebuchet