SSDC Document Deep Dive - Code Review Checklist

[swatts]

Hello peeps who build stuff with pictures and wires.

SSDC stands for Structured Software Design Consultants, it shouldn't therefore be a surprise that we have a pretty structured approach to the software process. We like checklists, so here's a closer look at our code review checklist.

First lets talk about reviews.

Commonly we have design reviews with our customers and these are usually mile-stoned as part of the project and will involve prototypes, drawings, presentations, sketches....anything really that can inform our customer what we think we should be delivering.

Less commonly we have internal design reviews and these should happen before any (or much) code is written.

Finally after code is written we have code reviews and these come in two forms; quality audit or collaborative.

The quality audit is done by grim-faced QA types in regulated industries (or companies that favour process over people). I'm going to ignore it as I fundamentally disagree with the approach.

Now let's talk collaborative code reviews. This is where a team gets together as equals and reviews each others code. Done right it's a learning, team-building, democratic, process building and teaching exercise.

We have a document for this. Actually that's a bit misleading, what we have is a document that should be applied prior to the code review. All SSDC documentation is in a repository and can be updated by anyone.

First off we want to do some initial checks.

Notice how we explain why it is important in the details part. My theory is that if you cannot give a good reason for doing it, it should be deleted.

Next we want to ensure the project is set up to our standard.

This helps make sure the project is repo ready. Next we need our project setting up.

The point of a checklist, and the reason we're fond of them is that they help us remember the mundane stuff. That's the project all sorted, now we move onto User Interfaces.

The latest addition to this document it with regard to making user input safe. Again it's a mental trigger. We call standard front panels that aren't user interfaces...

 Then we check out the block diagram.

 Finally we make sure the icons are up to scratch.

I'll reiterate that we could use this and go through the code in the meeting or we could tell the reviewees that we expect these to be sorted prior to the review.

The actual code review can then concentrate on the important things, like complex areas of code, areas that need more explaining (simplifying) and other useful stuff. Hopefully all the attendees will gain knowledge and share knowledge and the team will start to accrue best practices and agreed designs.

In future deep dives will poke around in some of our other documents, it will be a wild and crazy ride!

Lots of Love

Steve