Pavel,
just my 2c.
> Current status:
> We have that system already in place, because many changes made to the
> Firebird source tree are subject of review by at least one developer. But
> at least some (I hope that only some) changes are not checked at all.
> Actually, we haven't any shared knowledge, that peer review is really
> utilized in our project. Of course, some bugs were catched that way, but
> we don't know from others to what degree they do the review of changed
> code (if at all). There is not any developer designated to this task.
>
> Questions for you:
> 1) Do you think that we should use peer review ?
Definately, attacking quality from black box (it does what it says it should
do) and visual inspection (it works, but boy does is do a bad job of it or
leaks like crazy or won't work on the 29th Feb) give the best chance of
catching bugs IMO.
>
>
> 2) If yes, is the current state satisfactory for you ?
Not really as the real value comes when you can sit in your Project manager
/ Risk managers chair and feel comfortable that you have the following:
1) Coverage - i.e. every line of code has had someone eye over it.
2) Quality Review - Pavel developed a bit of code that had a certain bug in
it and Jason reviewed it and didn't find it. Report on code that Jason has
been the sole reviewer for optional re-review.
3) One piece of code has been reviewed by no-one and another has been
reviewed by everyone under the sun.
>
> 3) If not, what changes do you recommend ?
A coverage matrix / DB / whatever that allows the coder to leave their mark
(as it probably does now in cvs) + the ability for the reviewer to leave
their mark that they have reviewed it, then prior to release a risk
assesment can be made and any spare volunteer hours can be allocated to un
reviewed areas of the code.
>
>
> Your comments would be greatly appreciated.
> Best regards
Finally where I have been responsibel for setting up peer reviews, people
have ended up reviewing style over symantics, which doesn't help much.
Cheers,
JAC.
|
