How to integrate code reviews to a team [duplicate]

Question

I work in a team that keeps growing. However, there are no code reviews and I see this as a problem every day. There are people with really limited skills committing code to our repository that I believe should not commit.

I'm not the team leader nor am I in a management position. I already proposed code reviews about 6 months ago and there was no feedback received. Nor were there any code reviews.

I know code reviews would benefit everyone including the more experienced. Has anyone had any experience trying to integrate code reviews in a team? What did you propose and how did you do it?

Answer 1

Lead by example, even if you aren't the leader. The first step might be for you to start asking other team members to review your own code. Even if there isn't an official team policy, just start doing it. If there are people who are equal or less in experience to you, offer to review their code for them. Even if the team as a whole doesn't adopt the practice, at least you'll personally reap the benefits of peer review.

You might also look at some off the shelf review tools, and try to configure and install one on your box or on a common server. Then, you could offer to demonstrate this to everyone over lunch.

Answer 2

As an end contributor, your options are limited. The best you can do is try to figure out what's important to management and show how your solution (code reviews) impacts that. See also “Too object-oriented” and What to do when your colleagues don't value code maintainability [duplicate].

You may want to consider looking around for another position. Life is too short to waste in junk shops if you're not in a position to make things better.

Answer 3

Everybody agrees on their value, but it is hard to get consensus about how to bring them about.

If there aren't coding standards in place, you're left with either de facto standards or POV.

You might have one developer who is very hot on design patterns whilst another writes his new language in the style of an old one he used to develop with.

Also - whose code gets reviewed? If it is just junior staff they may feel aggrieved as may more senior staff who have to take time out to do it. The real value comes when it is 360. Junior developers get to avoid certain pitfalls whilst senior developers can offer their wealth of experience.

I realise none of the above directly answers "how to get started". But if you can't sell it or suggest a basic framework, you don't stand any chance of it being taken up.