Code duplication, refactor?

The words repetition repeated three times in a notebook. The book is on a wooden table next to a pen and a coffee

Code duplication or DRY (Don’t repeat yourself) is a core principle of software development. The principle itself is solid, duplicated code can and will become a problem. If you have a bug in a piece of code that ends up being duplicated n times you now have n+1 bugs. If you adjusted or tweaked the functionality of duplicated code, same issue, you need to make the same change n more times.

We should try to remove code duplication, which is a given, the question is when?

As with everything, there isn’t one answer, it very much depends on circumstance. For the purposes of this blog post, I’m going to focus on web development. Much of what I mention will apply regardless of the context.

Duplication in views

I’ll start with the easiest one to answer, duplicated code in your views. Views are typically the simplest part of your App. When you have duplicated a section of code more than two or three times, go for it. Create a view component, fragment or whatever your tool supports to remove the duplication.

It is less likely that your view code will fundamentally change, removing the duplication early makes sense. As your experience grows, you’ll end up removing any duplication before it occurs. This makes sense for simple view code that you will most certainly use multiple times.

Controllers

With controllers it depends on what code is duplicated. Is it flow code or is it Business code that should really be somewhere else and shouldn’t live in your controllers.

You should remove duplicated flow code but you shouldn’t make it your priority. Business code deduplication is your priority, it is the code which makes your App do something useful and interesting.

When you are confident you can remove some duplication, go for it, this could be Request handling code, code to prepare the view, whatever lives in your controllers. A good tip, open two controllers’ side by side and look at the code to see the repetition. You will be surprised at how much code you have duplicated and as a consequence, how much you can remove.

Business logic

Duplication in your “Business” logic is a problem. Duplication at this level will eventually hurt you as you will end up with inconsistent behaviour. This is the code which makes your App special, this is the code that you need to work. Problems here undermine your App and annoy your customers.

Regardless, it is still not as simple as “remove the duplication after n cases”. Your business logic is the most complex part of your App, this is the code you are most likely to tweak and adjust.

Before you remove any duplication you need to be certain the code solves your problem. There are going to be bugs and issues with your implementation, especially if it is new code. I would advise waiting a little while. Wait for the inevitable bug fixes or the feature tweaks, make sure the code works first.

We very rarely solve a problem correctly the first time, code inevitably gets rewritten. When you rewrite or refactor the code, remove the duplication then. You will have much more knowledge about the domain, and it won’t be surprising if you solve the problem in a completely different way to the original code.

Don’t worry

When you are beginning your career, don’t worry about code duplication. If a team member or a PR comment asks you to remove the duplication, obviously go for it. As you gain experience, you’ll know when you need to worry about DRY and when you don’t. Your only concern should be gaining experience and solving problems. Don’t worry about writing ‘perfect’ code, no one does.

Self-documenting API

A 3D render of a microchip with the letters API across its top surface.

Over the years I have worked on multiple APIs and created a few myself. Even though I have created several APIs I’ve only solely created one “large” API. Large is down to the reader and your specific experience. APIs which have a dozen or so endpoints can easily be documented in the project README. As soon as you have over 150 endpoints you need a plan, you need real documentation and a self-documenting API.

Definition

What is the definition of a self-documenting API? I have no idea what the official definition of the term is, below I’ve listed my requirements. If I’m way off base here, awesome! Let me know how I’m wrong, you can reach me on Twitter and via email.

Route list

When a developer makes a call to the entry point of your API, the response should document the features. That initial response should include a list of all the routes and the endpoints supported by the API.

We should all read the official documentation for tools we use but as we all know, documentation can easily become stale. If the API lists all the routes and endpoints the user will immediately know where to start looking for what they want.

Version, README and CHANGELOG

In addition to listing the routes and endpoints, the entry point for the API should list the version and include links to the README and CHANGELOG. Bonus points go to the developers who include a changelog endpoint within their API.

OPTIONS

The first two points are nice to have, however, they don’t make an API self-documenting.

Every route should support returning an OPTIONS response. The OPTIONS response needs to provide details (documentation) for the route, The response should list the supported endpoints, the fields and parameters required for each endpoint as well as a general overview of the route.

To see a working example, please make an OPTIONS request to https://api.costs-to-expect.com/v3/resource-types.

The response details the supported endpoints (verbs). The POST section details the fields which can be posted, the data type, validation rules and allowable values for linked data. The GET section details the supported query parameters and the supported sort, filter, and search fields.

Every route of the Costs to Expect API supporting returning an OPTIONS response; they are equally detailed.

Docs?

Yes, the Costs to Expect API still has documention, as great as OPTIONS responses are, you need to provide more detail sometimes. The Costs to Expect API documention lives on Postman and is in the progress of being moved to a GitHub repo.

Regardless of the size/complexity of your API, you need documention.

The longer your API lives the more important the documentation becomes We all forget the specifics after a long enough period, having an API which documents itself pays dividends down the line.