Clean coding at baby steps

Despite the example I’m going to share with you it is a simplified component of a very little service, the basic concepts are aplicable in general on most scenarios, as the conclusions at the end.

Context

We wanted to create a simple processor that, given a message from a queue, extracted and pushed useful data to another service. The queue had different types of messages published by our development tool (called Jarvis), on each relevant step of the development process (as component creation, build, deployment, release, etc.). The target service was a known management tool (JIRA), that could use that information to run some useful automation rules.

Refactoring

Let’s process just build events, we are happy with that

Pretty easy right? As it went well, let’s process deploy events too.

Nice!! What about releases? It would be also interesting to have that information (and this could go on, and on…)

Wait!. The code is getting difficult to read and a seems a bit repetitive….

Better! Aren’t all the events a bit similar? Let’s build a common interface.

Now, should the processor handle the mapping from the messages to the different types of events? It sounds like more that just one responsibility…

It’s a small class, and it seems easy to test too. Ok, but what happens with the event builder?

Well, at least it has one responsibility (build an event from a message), but it may be a big one! And it seems to be changing really fast as new events are added…What if we break this a little more?

Small and testable classes, with one reason to change. Great!!

Conclusions

Clean code, SOLID and other principles, good practices, design patterns, etc. definitely don’t come up from morning to night (and neither are always needed). What uses to happen, at least at my experience (and I think it’s the most appropriate way), is that you start with something that works (KISS!!), looks pretty nice, then the business changes, and it changes a little bit, and the business changes again, and it changes a little more…and well, so on. But, at some time, you realise that your code is not as nice and simple as it used to be, and suddenly one day you wake up at the middle of the night, with some crazy ideas on your head, and decide to do some refactor.

Your code is a language to express what you want; when you think it’s getting difficult (for you and others) to understand what it want to express, it’s time to clean it!. Be careful to procrastinate this task too much, because as LeBlanc’s law says, later == never. If it’s turning into a mess, your productivity (and your team’s) decreases, as trying to decipher and change the code consumes more and more time.

Clean code should be always pleasing and easy to read. And as you keep it clean, your team will care about letting it like that (a building with broken windows looks like nobody care about it and people stop caring; one broken window starts the process toward decay).

And always remember: you are an author, writing for readers who will judge your effort!!