Are you doing code reviews?
Thank God, you are.
Not?
Well, you are not alone. You know, most of your bugs could be killed by reviews. Most of your technical debts could be paid by reviews. Your team could collectively learn more by reviews...
Now, It's time to realize!
Start now! It's simple. I have found the following approach to be useful-
- Pair up with one developer. Make it explicit to the team. So, you know who reviews your code.
- Mix up a junior team member with a senior one, if possible.
- Have a fixed time, at least 30 minutes for each two weeks to do a team design/code review.
- Do it in small increments. We did the following-
- Sprint#1: Review variable/method/class/file/folder names only.
- Sprint#2: #1 + Review if/else blocks, loops.
- Sprint#3: #2 + Review class responsibilities.
- Sprint#4: #3 + Review test codes only.
The result is really worth
This first level feedback will help you to eliminate a lot of bugs, help in knowledge transfer and collective learning. Roughly, It takes only 10-15 minutes to review a code written in 3 days. I suggest, keep it simple.
One interesting thing is, many times I have found the developer him/herself actually found bugs/mistakes in the code before the reviewer at the time or reviewing.
A reviewer's eye will save lot of your time and money.
Update: Be constructive in your feedback! Example:-
Worst: This code is a piece of ...
Worse: This code is bad
Bad: This code is not good
Good: A better way is..
Better: We can also do it this way...
Best ?
One attention i would like to draw regarding this.Code reviewers should be constructive and positive about the comments made on the code written by others.If done with a TEAM mentality and positive attitude,Code Review is a great process for the overall quality improvement of code.
Code review should be part of life.
It increases quality of code, the programmer and the reviewer himself.