The authors provide a brief description of the two different approaches to unit testing - state based and behaviour based - I’m currently in favour of the latter approach and Martin Fowler has a well known article which covers pretty much anything you’d want to know about this topic area.

I really like the section of the book which talks about 'Zero Defect Count', whereby the highest priority should be to fix any defects that are found in work done previously rather than racing ahead onto the next new piece of functionality:

Another cool idea is that of time boxing efforts at fixing technical debt in the code base - that way we spend a certain amount of time fixing one area and when the time’s up we stop. I think this will work well as an approach as often when trying to fix code we can either get into the mindset of not fixing anything at all because it will take too long to do so or ending up shaving the yak in an attempt to fix a particularly problematic area of code.

I like the definition of abstraction that the authors give:

Maintainability of code is something which is seriously undervalued - I think it’s very important to write your code in such a way that the next person who works with it can actually understand what’s going on. The authors have a fantastic quote from Perl Best Practices:

There is a discussion of some of the design patterns and whether or not we should explicitly call out their use in our code, the suggestion being that we should only do so if it makes our intent clearer.

While describing out how to refactor some code to loosen its dependencies it’s pointed out that when the responsibilities of a class are a bit fuzzy the name of the class will probably be quite fuzzy too - it seems like this would server as quite a useful indicator for refactoring code to the single responsibility principle. The authors also suggest trying not to append the suffix 'Service' to classes since it tends to be a very overloaded term and a lot of the time doesn’t add much value to our code.

It is constantly pointed out how important it is to do refactoring in small steps so that we don’t break the rest of our code and to allow us to get rapid feedback on whether the refactoring is actually working or not. This is something that we’ve practiced in coding dojos and Kent mentions it as being one of his tools when dealing with code - I’ve certainly found that the overall time is much less when doing small step refactorings than trying to do everything in one go. I’m quite interested in trying out an idea called 'Bowling Scorecards' which my former colleague Bernardo Heynemann wrote about - the idea to have a card which has a certain number of squares, each square reprsenting a task that needs to be done. These are then crossed off as members of the team do them.

An interesting point which is made when talking about how to refactor data access code is to try and make sure that we are getting all the data from a single entry point - this is something which I noticed on a recent project where we were cluttering the controller with two calls to different repositories to retrieve some data when it probably could have been encapsulated into a single call.

Although they are talking specifically about poor encapsulation in data access layers, I think the following section about this applies to anywhere in our code base where we expose the inner workings of classes by failing to encapsulate properly:

The creation of an anti corruption layer to shield us from 3rd party dependency changes is suggested and I think this is absolutely vital otherwise whenever there is a change in the 3rd party code our code breaks all over the place. The authors also adeptly point out: