| This post was kindly contributed by NOTE: The Blog of RTSL.eu - Development With SAS - go there to comment and to read the full post. |
I’m a keen advocate for peer reviews. I’ve written about them before (here and here) but there’s always more to say.
Peer reviews must always be treated as a constructive exercise. The style of questions can play a big part in the atmosphere and tone of the exercise.
There are many ways you can judge the quality of code. It’s easy for developers to put too much time and effort in the wrong places, building things no one would use to begin with. So, aside from the basic questions of the code meeting design and coding guidelines, I ask myself the following questions:
a. How easy will it be to add new features?
b. How easy will it be to change existing features?
c. How easy will it be for a new team member to become productive?
I look for a good balance between the potentially contradictory questions. Using complex architecture might help with (1) and sometimes (2) but will probably hurt (3), so there is an interesting compromise to be delivered.
These questions ensure that the review takes account of the productivity of the team (and company) in addition to the regular technical factors.
| This post was kindly contributed by NOTE: The Blog of RTSL.eu - Development With SAS - go there to comment and to read the full post. |