We are using Scrum at work. As an eXtreme Programmer to the bones, I wanted more collective code ownsership. We were already doing some pair programming from time to time, but I thought it might be a good time to try public code reviews.
I have already been doing code reviews in other jobs, but the experience has been disappointing up till now for the following reasons :
- Even with review tools, they involved too much manual efforts
- I’ve been in jobs with reinforcing loops : In this kind of environment, even mandatory code reviews tend to become a useless “tick in the box” operation
- Often they are used as a control mechanism rather than a share tool
Public reviews, as discribed by Karl Fogel in Producing Free Open Source Software on the other hand seem something great to encourage share and peer review. The principles are simple :
- All commits must be reviewed by at least one person
- Anyone can review anyone’s code
At work, we are using Perforce and Code Collaborator as a review tool. We did not have the possibility to send an email at every perforce submit, and manually creating code collaborator reviews for every change is a chore. I spent an afternoon writing a small ruby script that polls perforce for new changes, and automaticaly creates reviews in Code Collaborator from these. I also added something to spot existing Jira ids in commit messages, to enlarge the existing review instead of creating a new one for every commit.
We are very pleased with the result, all the team is participating to the reviews. As with all good code reviews, it’s helps :
- Spoting some bugs
- Spoting some possible design improvements
- Discussing the global design and architechure of our system
- Gathering coding standards