Hacker News Reader

Comment by lostcoder | Hacker News Reader

I'm fortunate enough at my company to not have to submit to the code review bureaucracy - and I can justify it by having metrics which indicate that my code ships with fewer bugs than the code of other teams which do go through code reviews.

I think everyone should have some level of freedom to work in a manner which works best for them, rather than forcing everyone into the same process. Success should be measured by achievement of business goals and revenue.

For every anecdote you have about code reviews finding bugs, I have my own anecdote about people writing code going through a thorough code review process and the code crashes the first time an end user tries to use the functionality.

So yes, code review IS optional if you can justify it.

View on HN

What's the justification here though?

Saying "my code is better than other teams' even without review" does not prove that reviews are not helpful - maybe if you get your code reviewed you'll ship even fewer bugs, and if other teams don't review they'll ship even more bugs.

Further, eliminating bugs caused by any individual code commit is not really the goal behind code reviews in the first place. Finding bugs that the user notices on immediate use is an indictment of the QA process (whether manual or automatic).

Code reviews help maintain sanity in the code base, and are useful for sharing knowledge (both in terms of quality of code, and ensuring that there are at least 2 people who have some idea behind the code written). It provides an opportunity to have it read by someone who doesn’t share the same priors as you and helps you identify sections of code that may be confusing for another developer (including future you).

If Code review does lead to the identification of bugs that’s just a bonus.

There’s a reason Code review does not have a “run the code and test it” component to it and is entirely focused on code, and not whether it runs correctly.

>Code reviews help maintain sanity in the code base

But why delay the shipment of features/fixes to the customer for any of these reasons?

If code quality and human understanding is the actual rationale, it could make more sense to review code after it has shipped. In that way, it would cease to be a bottleneck for the developers or customers. Additionally, any bugs that appear in production could be accounted for during the refactoring process.

Saying that there is value to a practice is the easy part. We're forgetting to ask when to code review and whether or not code review should ever be a blocker to other processes.

Because in most environments it's unusual that a developer would go back and change the code after shipping it -they'll have e.g. another high priority bug to fix. Reviewing and refactoring code prior to shipping helps to keep development going sustainably, reducing build up of technical debt.

> people writing code going through a thorough code review process and the code crashes the first time an end user tries to use the functionality.

This is not an argument against code review. This means that the change wasn't even ready for code review. Whoever put up those patches skipped the step before it, where they verified the functionality of their own code.

Code review shouldn't -- can't -- be a time for someone else to mentally (or actually) execute the code and sign-off on it being bug-free. It's a sanity check for read-/maintain-ability. You can generally validate that the patch isn't doing something stupid or dangerous, but it's 100% on the submitter to ensure that their code works. If you have people putting code up for review without testing it first, then you have a bigger (people) problem, that code review will never be able to help with.

You are on a team though. If you are better than everybody else then your team is missing out on your code reviews.

I like how you emphasise the "IS" instead of the "if".

Sounds like you have bigger problems than code review!

Reply on news.ycombinator.com