4 ms·

Code review is good in general; however, it's a chore for the code reviewer. There are very little incentive for the reviewer and it always cuts into his sched

by ww520 15y ago

Code review is good in general; however, it's a chore for the code reviewer. There are very little incentive for the reviewer and it always cuts into his schedule. Unless the team has set up very clear incentive for code reviewers, it will become a rubber stamp routine.

kaelspencer 15y ago
The dev team I am on currently has five people. With all of us working in the same code base, I find the code reviews are a good opportunity to understand the changes my fellow developers are making. While reviewing code isn't strictly required on my team, having your code reviewed generally is. My personal incentive for reviewing is for my own understanding.
ori_b 15y ago
"I have to maintain this" tends to be a good incentive.
- nikatwork 15y ago
  not to mention, "you approved this yet it broke prod"
kamens 15y ago
We all review frequently and this hasn't happened to us yet. Our reviews are extremely helpful. It has to be seen as a very core part of the dev team's culture. I also explicitly asked this question to some ex-Googler team members about Google's code review culture (similarly required reviews) and heard that rubber stamping is by far the exception even at their size, not the norm.
HeyLaughingBoy 15y ago
Then account for it in the schedule. SEI has metrics that estimate the amount of review time needed vs. coding time, you can use that for a start and update with your own data. As far as the incentive: I really don't much like reviewing code either, but the bugs will be found one way or another. Either by you or your customer. Better they be found as soon as possible.
bwarp 15y ago
This is where we are. We use Crucible/Fisheye as well which really just makes things painfully hard.
- jonstjohn 15y ago
  We actually use Crucible and it our process is very smooth. Every development task must have a review created for it (usually spanning several commits) and one other person reviews the code. When the reviewer is satisfied, they give their approval and the task is closed. We do reviews for nearly all committed code.
brown9-2 15y ago
The incentive is better code, catching issues much much earlier, and more awareness on the team. How is that not worth a few extra minutes per changeset?

by ww520 15y ago

kaelspencer 15y ago

The dev team I am on currently has five people. With all of us working in the same code base, I find the code reviews are a good opportunity to understand the changes my fellow developers are making. While reviewing code isn't strictly required on my team, having your code reviewed generally is. My personal incentive for reviewing is for my own understanding.

ori_b 15y ago

"I have to maintain this" tends to be a good incentive.

nikatwork 15y ago
not to mention, "you approved this yet it broke prod"

kamens 15y ago

We all review frequently and this hasn't happened to us yet. Our reviews are extremely helpful. It has to be seen as a very core part of the dev team's culture. I also explicitly asked this question to some ex-Googler team members about Google's code review culture (similarly required reviews) and heard that rubber stamping is by far the exception even at their size, not the norm.

HeyLaughingBoy 15y ago

Then account for it in the schedule. SEI has metrics that estimate the amount of review time needed vs. coding time, you can use that for a start and update with your own data. As far as the incentive: I really don't much like reviewing code either, but the bugs will be found one way or another. Either by you or your customer. Better they be found as soon as possible.

bwarp 15y ago

This is where we are. We use Crucible/Fisheye as well which really just makes things painfully hard.

jonstjohn 15y ago
We actually use Crucible and it our process is very smooth. Every development task must have a review created for it (usually spanning several commits) and one other person reviews the code. When the reviewer is satisfied, they give their approval and the task is closed. We do reviews for nearly all committed code.

brown9-2 15y ago

The incentive is better code, catching issues much much earlier, and more awareness on the team. How is that not worth a few extra minutes per changeset?