I've Got Something For That

Much like when someone disappears into a shed and emerges with the perfect tool for a particular job developers can often be heard saying "I've written something a bit like that before".

As I've said many times a good developer is a lazy developer, re-using what you've previously written should bring a smile to every developers face.

But how can we increase the chances that these opportunities will present themselves, what is it that makes code re-usable?

Simplicity Over Configuration

An easy trap to fall into is to take a piece of code thats fairly close to what you want and makes the bits that don't quite fit configurable.

While in a lot of cases this will yield a nice solution care must be taken to ensure that this won't run out of control. An object with a vast number of possible configurations can be difficult to get to grips with, what you need it to do might be in there somewhere but your eye isn't drawn to it.

This is more likely to happen when your trying to re-use code in a large block where the desired functionality is always going to be custom based on the context its being used in.

The answer to this is composition, by breaking this large code block down into small, simple, easy to understand building blocks you allow for different configurations of the functionality by allowing the developer to build the functionality that makes sense for them while taking advantage of the effort you've put in to taking care of the lower level details.

Layering the Pie

In a similar vain composition is easier to achieve when your code has a clear hierarchy taking us from low level detail all the way up to chunks of functionality that a user would recognise.

These functional blocks will very often be able to traced back to the same lower level detail.

By working out at what level certain pieces of code should exist you can avoid duplication and move towards a toolbox of code.

Obvious examples of this would be a data access layer or a networking layer, but even here recognising that there is a common pattern to how network requests are built, queries are constructed or results are interpreted can help the extract, abstract and re-use cycle that we are aiming for. 

Guarantee Included

Identifying that a piece of code might suit your needs is only the first step, it would be nice to also have some evidence that it does do what it claims.

This could come by reviewing the source code but it wouldn't it be better to have the code come with a guarantee of its effectiveness.

This evidence should come in the form of unit testing, those test results should not only demonstrate that the code works but also act as documentation for how the code is expected to be used.

This testing as documentation approach will help re-enforce that this is the piece of code that you've been looking for, this will solve your problem and enable you to move forward.

All this means that testability should be seen as synonymous with reusability, along with the guarantee and documentation elements the qualities of code that make it testability such as loose coupling will also make the possibility of reuse much higher.

While in many aspects of engineering becoming obsessed with a single element of the design may not be optimal striving to make something reusable will naturally lead to many other qualities.

Sometime code will be custom to a particular situation but a divide and conquer approach and thinking about how code will interact can help minimise these situations and help a developer be a a lazy developer.