Infinite Undo!RSS

Data-Mining In The Git LogFalsehoods About Time


 
 

buy Unit Testing Is Not A Crime Stickers

Software As Narrative

How-To Articles

Devops Reading List


CC Sharealike © 2020 by Noah Sussman

Mar
20th
Thu
permalink

Do you do code review?

Marie Antoinette doing code review, apparently.

I’m always interested to hear from organizations who are trying to put automated deployment/testing in place, but have given not a single thought to instituting a code review process.

In such cases I always want to ask: if no one reviews anyone’s code then how the hell do you know what you are testing? The answer (if there is one) is always some hand-waviness about how actually some teams do code review and/or “that’s on the road map.”

No code review? Really? Really?!?

Code review is not optional.

Forget about the pyramid of testing — implementing any kind of deployment pipeline automation without code review is game over. Why? Because code quality is all about comprehensible code. Code review is the stage in the deploy pipeline where comprehensibility (or lack thereof) is evaluated by the simple expedient of… having at least one other human being look at your code and decide if it makes sense, and if it does make sense then is it good enough to deploy to production?

Without code review, testing cannot tell you anything meaningful. Of course code that’s never been reviewed has bugs. Duh.

What is code review?

Refer to the Joel Test. The last question is: “Do you do hallway usability testing?”

All “hallway UX testing” means is: do you get at least one other human being to look at your designs before you start implementing? Code review is similar.

All “code review” means is: do you get at least one other human being to look at your code before you integrate it?

How does code review work?

Here is a simple recipe for code review:

  1. Turn to your left.
  2. Do you see another programmer? Tap them on the shoulder.
  3. Show them your monitor.
  4. Say: does this make sense? Because I’m about to push it to prod.
  5. Listen to what the other programmer says.
  6. Make your own decision about whether to change the code and/or push to prod.

That’s it.

Now, I can sell you lots of sophisticated code review tools and I can then spend a bazillion hours customizing those tools. But all that code review tools can do is facilitate the process described above.

Simple tools for code review

Here are the simple code review tools I’d recommend if your organization employs fewer than 5,000 software engineers:

  1. less
  2. diff, or wdiff where line breaks are lacking
  3. GitHub pull requests

That’s it. There are tons of code review tools out there and I’ve never heard one engineer say they loved any of them. As far as I’m concerned, less, diff and pull requests will scale pretty well as long as your primary use case is asking another human to verify your code is not insane.

If your code review process is so complex that it requires a ton of tooling, that’s almost certainly because you’ve acquired some unnecessary ceremony that you could remove. Bring the pain to me on Twitter if you disagree ;-D

Gandalf with a laptop