3 ms·

> Foster a good code review culture in which finding defects is viewed positively Any tips on fostering this sort of culture? I personally am vary grateful whe

by mfonda 13y ago

> Foster a good code review culture in which finding defects is viewed positively Any tips on fostering this sort of culture? I personally am vary grateful when others point out defects in my code, as I view it as an opportunity to learn and grow as a developer. I try to encourage other developers on my team to have this attitude as well, and most do. However, I've worked with developers in the past who view anything pointed out in code review as personal attacks rather than a chance to learn. What can I do to help avoid this?

Aga 13y ago
I've worked in a couple of big projects (250+ developers) where we have introduced Gerrit Code Review [1] that has mandatory code reviews. In all cases, there has been a lot of initial scepticism and worries. Some things that I feel have contributed to people accepting code review, are: 1) Gerrit enforces code review, you have to get it done somehow, in order to get your changes in. It's integrated in the workflow. 2) You choose your own reviewers. 3) We have had a clear message, that code review is about communication, knowledge sharing and bug hunting is just an added bonus. And communication is always our biggest problem in big projects. Just by letting someone do code review of your changes, the knowledge inside the organization about the change has almost doubled. 4) We ask people to treat code review request as number one priority, as the changes can not get in before it. Before Gerrit we tried to encourage the culture by using Reviewboard [2], but in our case it just wasn't used that much. People did not treat review request as a high priority. Maybe because it was not enforced and sometimes you'd do a review for a change that the developer already merged in. It's interesting to see how small tricks can change peoples behaviour... [1] http://code.google.com/p/gerrit/ http://code.google.com/p/gerrit/ [2] http://www.reviewboard.org/ http://www.reviewboard.org/

by mfonda 13y ago

Aga 13y ago

I've worked in a couple of big projects (250+ developers) where we have introduced Gerrit Code Review [1] that has mandatory code reviews. In all cases, there has been a lot of initial scepticism and worries. Some things that I feel have contributed to people accepting code review, are: 1) Gerrit enforces code review, you have to get it done somehow, in order to get your changes in. It's integrated in the workflow. 2) You choose your own reviewers. 3) We have had a clear message, that code review is about communication, knowledge sharing and bug hunting is just an added bonus. And communication is always our biggest problem in big projects. Just by letting someone do code review of your changes, the knowledge inside the organization about the change has almost doubled. 4) We ask people to treat code review request as number one priority, as the changes can not get in before it. Before Gerrit we tried to encourage the culture by using Reviewboard [2], but in our case it just wasn't used that much. People did not treat review request as a high priority. Maybe because it was not enforced and sometimes you'd do a review for a change that the developer already merged in. It's interesting to see how small tricks can change peoples behaviour... [1] http://code.google.com/p/gerrit/ http://code.google.com/p/gerrit/ [2] http://www.reviewboard.org/ http://www.reviewboard.org/