For the first time, our team is taking a rigorous approach to technical code QA. We identify work to QA by picking out top level classes and QA'ing it and everything it calls or uses below it (and what they call/use etc.). I reckon our QA code coverage to be reasonably close to 100% and its an eye opener for me in terms of improvements both in code and design as well as catching bugs early. I'll definetly be promoting this in the future, but wondered how other teams approach techincal code QA. Do you have a rigorous approach? Do you aim to QA everything? Does one or two people tend to do it or is it spread evenly about the team? What do you look for when QA'ing? Any thoughts appreciated!
There's a couple of things we try to do:
1.) Code reviews can be too late. How about some pair/peer design, peer/pair programming to begin with?!
2.) Use static code tool analysis tools and checkstyle tools to get rid of the distracting fluff before you review what's really important. Much like reviewing an article in English, if there's a ton of spelling and grammar issues, then it's hard to review the real content.
3.) Come up with some agreed broad idioms that you want your code to follow, e.g:
- Code to interfaces
- SRP (Single Responsibility Principle)
- No re-inventing the wheel
- Dependency Injection of Factory lookups
That way you can build up a list of neutrally worded design code standards that you try to adhere to.
4.) Be darn sure to make it an encouraging and neutrally worded environment, you're playing with people's fragile egos here :)
"I like the concept and I think we can improve it by X" is better than "That's just plain wrong.".