August 17, 2017

...Learn TDD with Codemanship

Your House, Your (Code Quality) Rules

Picking up where I left off on the custom FxCop rules for the Codemanship Code Craft "Driving Test" has reminded me of something that's vitally important.

This morning I wrote a class that enumerates a type's collaborators. The code currently looks like this:

Codified in this class is an understanding of what I mean by a "collaborator", for the purposes of the driving test.

First of all, I'm not including non-project types. This is a judgement call to keep design rules realistic. My rule will limit the number of collaborating types to 3. If that includes core library types etc, it's going to be really tough.

I'm including fields, parameters and local variables. I'm also including the declaring types of any bound members. So if I call a method that returns an object and then I call a method on that, it'll be included.

I'm also not counting base classes as collaborators. Again, it's a judgement call.

I'm working alone, so I get to make the rules. But in a team setting that absolutely should not happen. Don't send the "tools dev" away to work in isolation on quality gates for Continuous Inspection. Because what will happen is, when they return and unleash their rules on the rest of the team, there'll be tears before bedtime.

The whole team needs to be involved. This is a great candidate for mob programming, in my experience. While you're waiting for business requirements in the early stages of a project/product, here's what the team could be doing to get the delivery engine up and running.

It will require the team to have discussions about code quality with a level of precision they probably never have before. I think this is a good thing.

Posted 1 month, 1 day ago on August 17, 2017