Thanks for the quick replies - I have ordered a couple of the books mentioned, so that I can swat up on the best way to approach the task of getting my department upto scratch. I am keen to put in some kind of monthly interpersonal code reviews - where by each member of the team reviews the others code to ensure that it follows the agreed standard, and suggest improvements etc.
My question is how do i put this into action with minimum resistance, certain members of the team i feel, would be resistant to change, and not so keen to better themselves/ their code, even though it is for the best.
Thanks
Dan | [reply] |
I'd recommend doing code reviews more often than monthly. If you do them monthly you really have to review everything that has been produced in a month in one go, which will take a long time. Long tasks which require lots of concentration tend to be done quite sloppily cos people get tired. And you have to review everything in one go, cos if not it could be many months between something being written and reviewed.
Better in my opinion to have weekly reviews, where one particular chunk of functionality is reviewed. In a team of four or five developers, this means that everyone has their code reviewed roughly monthly, and doing it so regularly makes it easier to get into the habit of doing them.
Not sure how to cope with resistance from the team. Frankly, people who aren't willing to have their code reviewed are people I wouldn't want to work with anyway. Cos if they don't want their code reviewed, presumably they don't want anyone else to maintain their code either, which is just stupid.
When I wrote our code review guidelines, I made it clear that code review is not meant to be competitive; it's not about finding fault with each other. It's about learning good techniques from each other and about helping each other. Perhaps you can break the ice by volunteering to be the first one have your code go under the microscope.
| [reply] |