“Let’s get Mikey the tester, he catches everything”
“I don’t make any mistakes in my code. go check on the junior developer”
“What’s wrong with a 200 line method? I mean that’s being pretty picky don’t you think?”
“Code Review? Seriously, I have too much work to get done. I am going to have to work till 3am just to get this feature working?”
I have rarely seen code reviews taken seriously. Despite extensive research and findings that demonstrate the value of code reviews, very seldom is it a core competency that developers have achieved. Most developers, PMs, and managers have heard these statements in some fashion and have done little or nothing about it. Below are my opinions on how to do a successful code review.
People are involved
While there are automated code review tools, and by all means use ones that make sense, people ultimately are involved.
- Respect the developer who wrote the code. Even if the developer has been gone for years. There are usually reasons why code was written a certain way that made sense at the time. I know my code from even 6 months ago could use some touch ups.
- There is no individual ownership of the code. Anyone and everyone on the team should be okay with changes that a developer makes, even if they don’t necessarily agree with the change. Discuss the reasons why the change was made and go from there.
- Everyone has strengths and weaknesses. Encourage and teach when you see a code review issue. Don’t assume that everyone should know how to implement code the way you do.
Define the Process
Code reviews are only effective when a consistent process for doing reviews is implemented. People get better at code reviews over time. when it becomes part of the standard development practice. Here are some process tips:
- Define the documentation that is needed during the review. Is the review in the form of an email, should it be a checked in artifact in your CMS system. Does it appear on the wiki page of your story. Decide and then be consistent.
- Specify what you are going to code review and publish it. Start small if you have never done consistent code reviews. Maybe you are just looking to review that the code base builds on a clean machine and meets the requirements of the feature or story the was developed. It might involve ensuring certain design patterns, naming conventions, or code formatting is applied. Start somewhere.
- Time box a code review and include it in your estimation cycle.
- Allow time for fixing code changes suggested in the code review. Most are relatively easy to fix. When something is big, understand the what it will take to fix it and get it scheduled as part of your technical debt.
Tools and Techniques
- Start with a team defined checklist. This will help to maintain consistency across the code review structure. DANGER: don’t be satisfied with a one time checklist. It can end up becoming a TPS report. Your team should reevaluate a checklist periodically.
- Use static code analysis tools. Don’t be afraid of tools like FxCop to help you make your code better.
- If you are working on a large change, get a quick buddy review. This can save hours in refactoring if you have made a error.
- Read the whole code, requirements, and test cases when doing a review. Get the whole context of the problem that is being solved.
Summary – My Dos and Don’ts
- Put down your co-workers
- Be too prideful to ask for a code review
- Be close minded to other coding styles
- Start doing code reviews
- Apply the code review suggestions to the best of your ability
- Implement Code Review techniques as part of your training program
- Identify good practices in the code as part of the review
- Have fun
How do you implement code reviews on your team? What suggestions would you have for improving the teams code review practice?