Are there any known alternatives for code review?

Question

Code review is part of the software development process, when all code written by one developer is checked by another, more senior developer, accepting it only after findings are corrected.

While reviews obviously increase the quality of code, somewhat not all developers really like or enjoy them very much. I will not reiterate on how this could possibly be, look here, here and even here maybe for the reasons of this question.

The problem I am trying to address is the power game problem. The reviewer has the huge power over the person whose code is being reviewed and can easily use it just to prevent that person from being successful with the project. Developer unwillingness to submit themselves for this power is also fully understandable. Also, some do write crappy code but then have arguments to reject findings as said above - also a problem.

Are there any alternative processes that could replace the code review for the goal of improving the code quality? Would it be possible to have something else instead of this process? While review may be required where software bugs kill humans, could some weaker method be sufficient where the situation is far from that critical?

This question is not about applying purely technical means like code formatters or automated testing frameworks, while these obviously reduce the number of bugs.

Answer 1

IMO you have misunderstood the technical process and this is causing a business problem. I will address both, because they are interrelated.

Technical misunderstanding: A code review is not a superior checking on the work of an inferior. A code review is a second (or more) pair of eyes looking at what was done, what was not done, how it was done, and how it solves the given problem, as well as how it fits into the current code and follows current coding standards. It is an acknowledment that our brains are wired to fill in missing details (search for psycholinguists and gap-filling to find details).

Business problem: your seniors are playing power games. This is probably at least partly caused by your misuse of code reviews. By having "senior reviews code of junior", you have established that (a) junior code needs review and senior doesn't (factually incorrect), and (b) that seniors do reviews. This has tied the reviews to positions within the company. Your senior reviewers almost have to find serious problems, otherwise they are saying that the juniors are as good as they are.

Solution: you need to either stop using reviews or start using them correctly, or you are going to have further problems as your seniors drive away your juniors in self defense.

Doing proper code reviews, reviews done by colleagues not superiors, is probably going to be hard. Seniors aren't going to want to have their code reviewed by juniors, juniors will be hesitant to correct code by seniors. Having juniors review juniors and seniors review seniors, will make matters worse. The only solution I see is to double down, have all code reviewed by multiple independent reviews for a time, until you are sure that everyone is onboard with the new process.

A LGTM (looks good to me) from one should be enough to commit, unless another reviewer has a concrete example of where the code doesn't work to spec.

Answer 2

Combining code reviews and power games is a recipe for disasters.

Here's the worst case: A and B have different styles. A writes code. B reviews. B complains that things are not in B's preferred style. A changes things to B's preferred style. If B had written the code and A had reviewed, A would have complained that things are not in A's preferred style. B changes things to A's preferred style. So we waste time to turn the code into the style that the author didn't like. That's nonsense, but it happens.

Long before the code is written, there should be a short discussion about the rough strategy. As a result the review shouldn't say "this is completely wrong and should have been done in an entirely different way" - that should be sorted out long before code is written.

Code review should find bugs, objectively objectionable code, and then it can make suggestions how something could be done better, or when a different style would be preferred. These should be suggestions. Bugs and objectively bad code need to be fixed, suggestions may be followed.

There is an exception: Sometimes the author himself thinks the code quality is low because there was not enough time, but there is time pressure and taking more time is hard to justify. In that situation the reviewer can help by telling the author to make changes that the author wanted to make anyway, but couldn't justify.

Answer 3

Code reviews are one way to increase quality and consistency, reduce bugs, and lower effort too. When everyone is familiar with all the code, they know what they can reuse from elsewhere, they know what will be affected by their changes, and they feel comfortable working in any part of the code. And as a second pair of eyes, they may spot errors before they cause damage. Note: in order to gain all these benefits there's no need for the review to be performed by a more senior developer.

Consistency is very hard to enforce any other way. Say the team has a style preference about the way names are constructed: is it AddItem() or NewItem() or ItemAdd(), for example. Someone who writes a lot of code which all works fine but doesn't follow that style may be told to correct it, and may feel that's a big giant waste of time. (Most tools can make these sorts of changes trivially, so the response is more generally an emotional one about liking to be corrected or not liking feeling "wrong".)

Bugspotting is rarer, but it does happen that someone will say "this doesn't look [threadsafe, scalable, exception-safe]; did you test under [typical production conditions that don't occur on a dev machine]?" and a real bug is prevented. Generally this means the person has to start over and feels really humiliated for having made a rookie mistake.

The downside to code reviews is that they can get adversarial. It's hard for a reviewer not to think "what were you even thinking? Did you read our style guide? Did you even consider what production is like compared to your laptop?" and sometimes they say those things too. Making it a review gate where a senior person can pass or fail you intensifies the emotions. Developers often try to rebut corrections, saying that it's a matter of personal preference or that the reviewer is obsessed with an edge case that won't happen, or is just making up concerns to feel important or to humiliate the developer.

Now imagine instead that peers looked over each other's stuff all the time. Not as a gate that you can't get through without a gold star, but as a natural way of working. And they pointed things out to each other early, to save work and pain, not to cause it. That would be much better, right? In the same way that continuous integration and continuous testing made developers happier and code better compared to code-for-two-years-now-the-testing-can-begin, little reviews all the time - many times a week - will make developers happier and code better than one final you-thought-you-were-done-but-The-Nitpicker-is-here code reviews.

If you want to drop them entirely, you could. Plenty of code has been written and shipped without them. But it's a risk. Tests passing doesn't mean the code is readable and consistent. Not blowing up in production the first week doesn't mean it won't when you double your user numbers, or have 5 years of stuff in the database. You would be hard put to find any substitute for looking at the code to prevent those kinds of problems.

Answer 4

I don't see how it can degenerate into a political issue. I presume that there are at least three people involved; two developers and a project manager.

Developer A code reviews the work of developer B. Developer B code reviews the work of developer A. The feedback circle is complete. If developer A decides to be really picky about the work of developer B, then they'd better be ready to accept a similar level of criticism back.

If it gets to the point where no code is being accepted, the project manager needs to step in and do a little project management with the development team and sort the problem out for them.