Code smells | 5 Helix smells to better understand antipatterns

Code smells | 5 Helix smells to better understand antipatterns
28th March 2019
News and Insights

Find out the five ‘Helix smells’ that should be in every Sitecore developer’s vocabulary to describe common architectural challenges

For those who aren’t too familiar with Sitecore Helix, here’s a brief overview to bring you up to speed. Helix is Sitecore’s official guidelines for creating solutions using a modular approach. Helix was designed to help combat the exponential increase in the cost of change that often comes with the growth of a site.

 

 

What are code smells?

In the book, Refactoring, by Martin Fowler a code smell is described as, ‘a surface indication that usually corresponds to a deeper problem in the system’. The book goes on to outline that code smells are:

1. Quick to spot (sniffable)

2. Require further investigation

3. Not always a problem

It’s important to recognise that these are not called ‘anti-patterns’ because code smells indicate a problem, that needs further investigation to determine whether action is required or not.

In the book, we see around 25 code smells identified. Each one is given a description, why it tends to occur and how it can be fixed. This gives developers a shared vocabulary to communicate common issues, I thought this approach would be useful for the Sitecore community, using Helix. So, at the Sitecore Virtual Developer Day I introduced, ‘Helix Smells’.

What are the key Helix smells?

Sitecore Habitat is the official Helix demo, built with all the best practices and techniques. A great place to learn Helix to see how the site implements best principles and for well-versed Helix developers to use as a reference when solving problems in a Helix solution.

However, Habitat poses some challenges which led to my first Helix smell:

1. Habitat Cargo Cult – Where developers blindly follow the look and feel of the Sitecore Habitat solution, assuming benefits will just manifest without understanding why it was built that way.

An example of this is when developers copy code or entire projects from Habitat. This poses several problems because doing so, includes code in the client’s solution that might be redundant and therefore not meeting the needs or requirements of the user. In some cases, solely copying the style, without the principles leads to the same issues, without any real benefits that eventually leads to useless, problematic code, that is representative of ‘a big ball of mud’ that Helix sets out to avoid. The hashtag, #HabitatIsNotAStarterKit has seen many of the Sitecore community rally together to stand against this ‘Habitat Cargo Cult’.

The next few code smells for Helix are closely related. For me, the structure of Helix should be represented with a more prominent feature layer (as below). This layer is more accurate to where the bulk of the code should sit, with emphasis that the Project and Foundation layers are there to facilitate those features.

 

Consider the scenario where you have two features that have custom URL requirements:

  • Products – URL’s have a product code in a query string (e.g. /products?id=123)
  • Blog – URL’s use a wildcard item (e.g. /blog/my-first-post)

A ‘custom link provider’ is commonly used in this kind of scenario. This code might be mapped onto the Helix solution with the custom link provider in the foundation layer. Although the custom link provider doesn’t rely on the feature layer in this set up, it is a messy and inflexible solution that I have coined as the Helix smell, ‘Fat Foundation’.

2. Fat Foundation – Where excessive concrete code is added to the Foundation layer, leading back to a monolithic solution structure.

 

 

3. Fat Project – Where excessive logic is added to the Project layer, leading to an inflexible solution.

Possibly one of the most alarming code smells for Helix is, the Unstable Foundation.

4. Unstable Foundation – Where code that changes frequently is added to the Foundation layer, with side effects that spread through the system.

When you look at the code, and divide it into ‘if’ statements, one currently dealing with product details and the other, Blog details. Whilst with only two features, this is manageable, as more features are added this class will become larger and more complicated.

 

 

This requires the foundation module code to change frequently. If you have multiple features and modules that are reliant on the foundation layer changing, this model risks introducing bugs and side effects throughout the system.

5. Unearned Foundation Status – Where code in the Foundation layer is only used by a single Feature module.

Another common scenario I see is when there are multiple features, but only one is dependent on foundation modules i.e. custom link provider. This adds complexity to the code unnecessarily. Foundation code should ideally have more than one dependent feature.

 

 

Learn more about Helix smells

After presenting my talk on ‘Helix Smells’ for the Sitecore Virtual Developer Day, I had a lot of questions about adding more code smells to the vocabulary. It’s good to know that there’s an appetite within the Sitecore developer community to continually improve the quality of the work we produce. I now hope to develop the idea of Helix Smells over the coming months.

You can watch the full Helix Smells presentation here.

Ready to join a team of Sitecore MVPs?

We have some of the best talent working for us at Kagool, including more Sitecore MVPs than any other UK agency. We currently have some exciting career opportunities across our Manchester, Cardiff and London offices. Including vacancies for:

Contact vacancies@bekagool.com today or visit our services pages to learn more about our extensive expertise.