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 ?
