Jomo Fisher--I mentioned a while ago that MSBuild team uses Test Driven Development (TDD). Afterwards, several people expressed interest in the general development process at Microsoft. Code Quality is an area that I care deeply about and I’ve tried a lot of stuff over the years to improve my own personal development process and the process of the teams that I’ve worked with. If there’s one fundamental lesson that I’ve learned it’s this:
Try lots of things to improve quality. Keep doing what works, stop doing what doesn’t.
This lesson implies that two things need to happen:
(1) You need a stream of ideas to try.
(2) You need to be able to recognize when something is working and when it isn’t.
The second part depends a lot on the dynamics of your team, your company and the industry you serve. What works for one team may be fundamentally broken for another. This is a balance that is unique to every development shop and so it’s hard to make generalizations about this.
For the first part, however, I think we can help each other. I have some ideas that have worked well for the teams that I’ve worked on. In this post and in future posts I’ll share these ideas, along with the pitfalls we ran into. If something sounds good to you, give it a try. Also, if you’ve tried something that has worked well for your team, I’d love to hear about it. I should mention that very few of these ideas are originally mine. These are mostly other people’s ideas that I’ve picked up over time
Without further ado, here is…
Tip #1: Do Codereviews Before Checking In
This tip assumes your team uses some sort of source control. I know this isn’t true for every team, but I think this is valuable enough to mention anyway.
Here’s how this works on my team. Once a developer is done writing a chunk of code, he asks another developer for a codereview. The two developers sit down and go through the changes line by line talking about the impact of the change. We use a tool called WINDIFF.EXE to help with this process. One way to use WINDIFF is to create two directories, one with the before code and one with the after code. Then call WINDIFF like this:
WINDIFF c:\before c:\after
The code review process has lots of dials that you can turn to suit your team. Here are the dials along with my own preferred setting.
When to do Codereviews—Do you review for minor fixes or do you save them for big, architectural changes? I like to get reviews for every checkin. The reason is that I view a codereview as a learning and communication opportunity rather than just a quality gate. Also, when you’re working in larger teams there’s a huge benefit to keeping the checked in code as high-quality as possible because every flaw that makes it into source control gets multiplied by the number of developers that will eventually experience that flaw.
Picking a Codereviewer—Some shops like to let only the senior developers do the reviewing. My preference is to let everyone review code. The reason is that this can be a learning process for both reviewer and reviewee. While a senior developer may catch more bugs, a junior developer will get exposure to how different areas of the code work.
Authority—Who gets to make the final decision when there’s a disagreement? This part has to be up to your team. To me, the healthiest code reviews are those where the codereviewee is able to detach his ego from the code he has just written. This can be pretty hard sometimes. When I receive a codereview, I try to accommodate the reviewer’s feedback as much as I can and save my pushback for the areas that I’m most passionate about.
Detail—How much detail do you get into? Codereview feedback can vary from brace and comment placement to sweeping architectural issues. When I’m receiving a codereview, I find the best use of time is to just accept and agree to fix nitpicks so that we can focus as much time as possible on architecture. When I’m the reviewer, I try to focus as much time as possible understanding whether the change is structurally sound. If I have nitpicks, I mention them in passing and try to move on quickly.
Finishing—When is the codereview done? When I receive acode review, I like to send the reviewer an email about how I fixed each issue. I also give them the option of returning for a follow up codereview.
I’d be interested in hearing from people who’ve had positive or negative experience with codereviews. What worked for your team?
See Tip# 2: Take Maximum Advantage of Developer-Written Tests
This posting is provided "AS IS" with no warranties, and confers no rights.
PingBack from http://mikesdump.wordpress.com/2005/05/16/code-review-posting/