Introducing Code Reviews to an Org
Trying to introduce the subject of implementing Code Reviews can be a minefield.
The members of your team will either love you or hate you; but then again how is that any different from any other decision you make? Every single programmer that I have ever come across, no matter the discipline, is precious about their work. Whereby questioning the placement of a For Loop might as well be calling them an idiot. How you introduce this should be slowly and carefully. There are numerous ways you can do this;
1) Sit in a room with every programmer than can make it and walk through code line by line (bit boring for me) 2) Tools like TFS have Gated Check-in so that someone is always looking through code before it goes into the source 3) There are TONS of options out their online from fully fledged apps to plug ins for every IDE
For me however, the Pull Request via Stash is king.
GIT has many flavours and when I looked into how we could move our Source Control away from Visual Source Safe (I know) as well as introduce Code Reviews there was only ever going to be one winner.
How do you quickly and quietly introduce Code Reviews while making it a positive experience? The GIT Pull Request. Once again, there are many different GIT tools online that can do the job but for us Stash hit the mark. It has just enough flexibility in how it works to make sure I have the security that the master branches won’t have crappy code in them and combined with Sourcetree, it makes it easy to understand and allow GIT to work for you.
Now I’m not saying my team are GIT experts… but they don’t need to be.
What they do know how to do is keep Commits tidy, informative, clean and when moving their code from branch to master create a Pull Request.
That’s where the magic happens.
So far we have managed to go Code Reviews on VB6, ASP.NET MVC, VB.NET and Objective C; that’s good going.
No matter how you tackle quality within your team try and make it fun. Nobody likes to be torn apart… at the end of the day if we are in a Code Review; the product has been tested and is working.
What the review should be used to do is share insights, make other team members aware of any issues that were had implementing said Code and also giving possible other avenues that the work could have went.
It needs to be fun.
Bring the fun and you’ll bring the quality.