Code Reviews

I had a conversation at work today about code reviews... I made some connections that I've not really had before.

So, let me start off and say that I like code reviews. They are a good way of maintaining good overall code quality.

But then at the same time I hear things like "I don't know how that bug got to production, the broken code had all these 'ship it's."

Taking a step back, the use of code reviews mainly finds structural problems in the code like naming, spacing, and the like. It can also be used to find small optimizations. The very best is having someone hit the abort because the overall strategy is flawed. It's also good to spread knowledge around a team.

But it's not a bug-catching panacea at all. This is a human-driven static analysis of the code.

What I do see sometimes is people using a "ship-it" as a way of directing blame elsewhere for production problems.

"I got this code CR'ed and no one else caught it either."

"I got this code CR'ed and no one else caught it either."

Well, good for you. You got some people to look at the code -- people who aren't nearly as close to the problem as you, and they didn't catch anything.

But the buck still stops with the coder and tester who pushed to code out.

Reiterating: I like code reviews. But you have to be cognizant about what classes of problems you can possibly catch with them.

Previous
Previous

Theme update fail

Next
Next

Friends