A mirror…It can make a difference when you’re getting ready to go out, to go to a meeting, or even to have a video conference call. Taking a look in the mirror, by itself, doesn’t fix anything. But knowing that it’s about to be show time, you take extra care.
The same goes for your code. A code review process is like looking in a mirror. By itself, it fixes nothing. But knowing that the review coming up will probably cause a developer to become more conscientious over time.
Since Microsoft has opened up its ecosystem to open source resources like Git. Because of Git’s flexibility, development managers sometimes wonder how to enforce best practices. There is a fairly straightforward way that you can use that combination to improve your codebase.
In a recent MSDN post, you can learn to to enact a system of peer reviews via branch and build policies. You can even specify the names and number of people you want to serve in the capacity of peer reviewers. The advice also includes throwing in some code analysis for good measure, which I also covered in a previous post on this site.
It’s probably a good idea to implement all of the advice here. Try some of it on for size, and if your quality improves, add another step. In any case, taking an incremental approach will likely get more cooperation.
However, don’t let your disagreement with one or more of the recommendations hold you back. Don’t say you don’t have time…you do. The branch policy, in particular, will save your engineers and managers alike lots of time.
Instead of chasing down individual developers, project managers can simply check with the designated peer reviewers when they have questions. This keeps your team humming, with minimal interruption.
Happy coding, and feel free to chime in with your opinion.