Archive

Posts Tagged ‘process’

Code Review for Dummies

April 24, 2010 Leave a comment

Early on in my college days, I realized that not every “CS major” can actually write coherent code. Some people chose computers because they were pre-law, others thought it would be good money, etc. And then there were the true nerds. Kids like me who’d been coding since their early teen years, who ate/slept/breathed and even dreamed code. Kids you’d be afraid to walk on the same side of the street with… kids who think in 3D coordinates and analyze the algorithmic complexity of setting up a row of folding chairs.

I think the real shocker for me was one college professor who couldn’t actually code at all. The guy was a flippin’ genius with algorithm design, pseudocode, and dynamic programming principles – but he couldn’t write actual code that would compile and run on a real computer.

And then there was me. I was a freakin’ code rockstar. I led group projects, wrote awesome code and turned in all my projects early.

Yeah, I thought I was pretty hot stuff.

A few years later, life smacked me up side the head a few times and I slowly, ever so slowly came to realize that I write bugs too. It’s true that programmers have different levels of ability, and there are plenty of code “posers” who can’t code their way out of a paper bag – but everyone has bugs, sometimes really stupid ones. And sometimes, even when code is written and tested, validated to be functionally correct – sometimes, it’s not fast enough. Or it uses too much memory, or it’s not portable to Mac OS, or you lose all your data if the power cord gets yanked out of the wall.

Code reviews can’t solve world hunger or promote world peace, but when done correctly they save time and money. I’ve personally seen code reviews find and fix critical bugs of every flavor and type, and the process pushes code in the direction it really should be going.

I haven’t met very many professional software developers who actually argue against code review… but not everyone actually does it. And even when people do reviews, sometimes the review process is fundamentally flawed and ends up wasting time and money.

And now we finally get to the topic at hand: code review for dummies.

Or putting it another way, here’s some concrete steps you can follow to make code reviews work for you instead of against you.

  1. Put time in your project schedule for code reviews
  2. Use a code review tool like Review Board or Crucible
  3. Establish sane code standards, and enforce them frequently

This list is by no means perfect, but if you follow these suggestions you will be well on your way to amazing code reviews. Let’s take a moment to discuss each idea in brief.

Schedule Time for Reviews

It seems like something so duh obvious that it’s not worth mentioning – but this can actually be the most difficult part of code review.

If you don’t schedule time for code reviews, they just don’t happen. It’s pretty rare when a developer will spontaneously conduct a code review or code walkthrough instead of writing new code. And if your modus operandi is like most software teams, your project is weeks/months overdue and it’s down to crunch time… not the kind of environment that most developers will find condusive for reviews. That is, unless there’s significant managerial support and/or prodding.

Use a Code Review Tool

I literally shudder whenever I hear the words “Fagan code inspection.” If you’re not familiar with Fagan or his uber-complicated, much abused process – go read about it.

I think the concept of a Fagan inspection is really great – for software projects that are adequately funded, with teams that execute the method perfectly, and have long software development cycles. And I’ve never seen all of those conditions met. Nobody ever comes to the meeting having read the code, and invariably it turns into a drawn out brawl over variable naming conventions.

Other approaches to actually conducting a review include developers emailing patches around, and “code walkthroughs.”

Emailing patches is not too bad, but it only works if all your developers know what a patch is, and how to use them effectively. And even then, you have no permanent record of the comments or decisions from the review. Well, technically you have a bunch of emails but the whole process is rather manual and makes any actual reporting or tracking of patches cumbersome.

Code walkthroughs are an extremely important and critical aspect of the software development process, and should be part of your code review process. But I won’t be covering this process here.

Lightweight code review tools like Review Board and Crucible are indispensable and make the review process… oddly fun and painless. Check them out.

Establish Sane Coding Standards

The less I say about this, the better off everyone will be.

You have to have coding standards to make your code readable and maintainable. Without coding standards, code reviews are pointless brawls.

‘Nuff said.


And that folks is the long and the short of it. Code review is an essential, vital part of any serious software development process. Not doing it makes you a dummy… so don’t be a dummy, follow my advice and you’ll be glad you did.

Best

Atto

Categories: Uncategorized Tags: , , ,