One of the most interesting things I had to get used to when I started my new job was a formal peer code review workflow. I’ve never really experienced code review before, certainly never in any kind of official way. The hardest part for me was getting used to what I perceived to be people “criticizing” my code. When in reality, I’ve learned, they are actually making both themselves as well as myself better coders! Not only that, but the product is better off for it! Its a win-win…win!
We use GitHub (enterprise), so our code review typically comes in when you submit a Pull Request. When I feel that my code is stable, tested, and refactored to my satisfaction, I can do all of my commits and then push my branch and submit a Pull Request. After that, I just sit back and anxiously await feedback.
GitHub is a great service when it comes to code review because developers and comment on specific lines of code and the diff view per Pull Request is really well organized. I’ve submitted a few PRs already that I have received generally really good and solid feedback on. I’ve learned quite a bit about my common coding mistakes and bad practice habits. I’ve debated on a few things and learned a lot during those debates too!
“It’s also important to remember that code review is a collaborative feedback process – if you disagree with a review note you should start a conversation about it, don’t just ignore it, or implement it even though you disagree.”
A discussion about implementing code review with a friend had us talking about the idea of “manpower” with regard to reviews being considered extra work. I understand that this could be a hard sell (especially in a non-developer-centric or corporate environment). One of the biggest impacts that code review is supposed to have is fewer defects – and at the end of the day any true software developer will say that that is the holy grail and end goal. If you can ship a product with fewer defects – just think of the impact that can have across the board (customer satisfaction, word of mouth, sales figures, innovation, etc, etc, etc).
Here are a few really great reads on more detailed approaches to code review and why you should implement (as well as how):
http://alexgaynor.net/2013/sep/26/effective-code-review/
http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/