It Helps if your Developer is DRY

It Helps if your Developer is DRY

I hear you say “I wouldn’t want to employ someone to build my website whilst inebriated but they don’t have to be teetotal”. To be clear I am using DRY as the acronym Don’t Repeat Yourself. And this is not verbal repetition but code repetition.

So why is this such a big problem and why should it bother the website owner? Well it will almost certainly concern you in years to come if you employ another developer or indeed invite the original developer back to enhance the website at a later date.

A typical example might be that there are a couple of hundred lines of code that fetch all the cars booked into a garage this week for repairs and display them on a page where they can be marked as completed or ongoing. The garage has a further requirement that enables their customers to see their own cars but nobody elses and not have the ability to mark the repairs as completed. The simple soution is to copy the 200 lines of code, add a condition that only the logged in user’s cars as displayed and remove the Mark Complete button. This can then be added to the customer facing part of the website. The desired look will be quite simple to achieve and will yield instant results.

What is the harm in the above you may say?

• If anything changes in the format of the car details – for instance more features displayed – the code will need to be changed in 2 place or 10 places or however many times the code has been copied, which is not so easy to figure out when you are coming to the codebase fresh
• If you are thinking search and replace will do the trick, apart from the risk of replacing unseen code if anybody modifies one of the copies this will not get replaced
• Code bloat. A developer facing a dozen possible code sources is like trying to find your favourite sauce in a cupboard full of sauces and can lead to “code blindness”
• In spite of the initially easy implementation future uses elsewhere of the car list will be more time consuming as the developer will need to decide which of the many variants of code to copy and what to modify
• Security and maintenance costs will be magnified by as many copies of the code as are present

So what to do?

The answer is to use as much abstraction as is efficient by:

• Using functions, methods or subroutines, which are all forms of containers that standardise the code and accept parameters which modify the output. For instance getCars(‘all’) and getCars(‘clientname’)
• Separate the code from the output on the web page by using templates. In that way the display can be dealt with separately from the logic and can itself be contained in a function
• Abstract as much of the logic to the “model” or part of the application that deals with the data. In that way the part of the application dealing with the control of data can use a centralized data model
• As a developer always look search the system for code that mirrors what is required before writing a new implementation

I have seen many cases of poorly coded websites that have become obsolete simply because the code is so difficult to read and contains so many trapdoors for the unwitting developer to fall into. Consider a simple recipe application I once had to work on. There were 64 recipes and 64 files! Adding a new recipe should have consisted of adding a new recipe to the database and letting the application do all the hard work instead of creating a new file with 98% similar content.