I spend a lot of time conducting code reviews these days. Far more than writing code in fact. As bold as it may be to say, I am the most experienced Web developer in my team. It pretty much came about because I’ve proven myself to be capable. With great power comes great responsibility after all!

Of late, I have been reflecting on how our Web strategy has evolved, and the resulting spider’s web that we are now trying to disentangle ourselves from. Deliberating over the last few years has got me thinking that many principles are language agnostic, not least code smells.

The Scent That Transports You Back

It is said that a single scent can transport you back to a happier time. Catching that first scent of tomato soup and toast will always take me back to my grandmother’s kitchen. My first memory of code smells comes from a lecture on Software Engineering at Glasgow University. While most students dozed lazily in their seats at the soft skills covered, I was engrossed in this idea of refactoring.

Code smells, like tomato soup, take me back to a simpler time

For those unaware, Code Smells are a term coined by Kent Beck, and utilised within Refactoring by Martin Fowler. These smells describe a symptom that potentially indicates a further underlying problem within the code base. Following that initial lecture, it wasn’t until several years later when I was in my first grown up job as a Software Developer that I actually read the book. It certainly didn’t disappoint. I’ll admit, all the examples were in Java, which I hadn’t touched for a couple of years. This introduced a learning overhead as I was forced to brush up on my Java skills. But the principles still made sense. And, for geeky me anyway, they sparked that same excited realisation that I could make our code more readable and understandable.

Moving Out West

Just under three years ago, I moved onto a new frontier, to the exciting world of Web development. The Web Wild West had historically been ruled by JavaScript. The language itself has some advantages, the key being that it enables pretty much anyone with the will to get dynamic Web pages up and running quickly. However, the lack of static type support does certainly lead to a multitude of errors if you are not careful.

This was pretty much the reason that we adopted Typescript from the outset. Coming from a Desktop UI development background, it made sense to utilise a language similar to C# to get us comfortable quickly. Deadlines don’t cease when you’re learning, and there were definitely no exceptions here!

We proved quickly that we could build out new, arguably scalable features in a short timeframe. This would have been the perfect time to re-evaluate our stance and ensure we were refactoring regularly as we go. Unfortunately, we were very much victims of our own success. Looking back at the code base now, not instilling further good practices including regular refactoring introduced a ton of bad smells.

I’ll not go into details of the God classes, large classes and methods, or even the huge number of copy-pasted code that I have seen. That’s not really the point of this thread. I will certainly admit that I regret allowing it to get to that stage.

Escaping the Web

We are now attempting some rather exciting things to try and escape the expansive spider’s web that we have created. By creating a modular-based UI architecture, we can split the features into logical groupings. That in itself has challenges that we are addressing. However, no matter how many modules we split these features into, we still need to address the stale code smells that remain.

> I don’t understand it. But for that matter > I don’t understand how a spider learned to spin > a web in the first place. When the words > appeared everyone said they were a miracle. > But nobody pointed out that the web itself is a miracle. > > E.B. White, Charlotte’s Web

Through peer reviews the collective have been imparting the advice they can. Our code quality is certainly improving. We are so far preventing the reintroduction of many of the smells we had before. Or, at least I thought that was the case.

Following a change in IDE this week to Visual Studio Code and installation of a Typescript supported complexity plugin, I’ve seen that a couple of smells are reoccurring. When considering why, part of this certainly stems from a lack of complexity metrics on our PR portal itself. However, thinking back to reading Martin Fowler’s Refactoring, I wonder how many of the next generation have actually read it?

Similar to Millennials being raised with the complacency that Technology is intrinsic in their lives, a lot of these developers have evolved with the mentality that refactoring tools have always been available in their favourite IDE menu. Does this lead to a lack of appreciation of where these ideas originate from?

This disregard seems to manifest itself in long methods in classes, among other foul code scents. It has resulted in an urgent set of tasks being defined in this sprint to address these particular problems. However, going forward we need to instil an appreciation of where the term refactoring truly comes from, and train our developer’s sense of smell to detect these bouquets.

Thanks for reading!