Evolving Code: From the Crust to the Core

From the crust to the core, where does the CSS go?

At Shopify, as our team scales, we’ve been trying to figure out how to manage the influx of new design and new components into the codebase. On one hand, we want all code to meet our coding standards, use the existing system where it can, and expand it when necessary.

As new functionality and new experiments get introduced, we are finding ourselves unsure how best to manage this.

Quick and dirty and refactor later? Problem is, people are lazy. Things might not get revisited and we’ll be left trying with the less-than-desirable code for some time.

Spend the time up front to “do it right”? It might limit our ability to iterate quickly if we fuss too much on doing it right. With experiments, much if not all of the code might just be thrown away anyways or changed with the knowledge gained from the experiment.

From the Crust

We’re approaching this now by placing code in the crust and then moving it to the core as it is refined and needed.

What does the crust look like from a code perspective? We have different files that we’ve been using:

Area files

Often times, the designs are specific to a section of the app. They haven’t yet been abstracted out to apply elsewhere.

Shame file

While not specific to one area, we know that this is code that we don’t want. We know that this is code that desperately needs to be refactored and will be tackled sooner rather than later.

Experiments class

This is relatively new. At the ruby level, we’ve done beta flags for years but hadn’t considered what this meant from a CSS perspective until recently. We’re trying an experiments prefix to identify stuff that will be tested and then decide what to do with it when the experiment is done.

To the Core

I have a motto as of late: “Make the right things easy and the wrong things hard.” I fear that these approaches make it easier for code to live at the fringe and that people won’t take the time to refactor the code, pushing it closer to the core.

However, I have been thinking about component systems — especially ones that live outside of the core product. In such a situation, having components developed on the crust that then ‘graduate’ to the core sounds like a good approach.

In this way, there’s a higher bar that would need to be met, due to the longevity of these core pieces.

In the world of Object-Oriented Programming, there is a saying: “Make it work, make it small, make it fast.” This is an approach that we’re trying on for size and will hopefully create the right balance of code quality.

Published November 17, 2014
Categorized as HTML and CSS
Short URL: https://snook.ca/s/1042

Conversation

3 Comments · RSS feed
Ren said on November 22, 2014

Do you have any code examples? Like on GitHub or Codepen? I've used shame.css with highly specific code or !important added. But I'd be curious to see how area and experimental code is written, named, and organized.

Ren said on November 22, 2014

Do you have any code examples? Like on GitHub or Codepen? I've used shame.css with highly specific code or !important added. But I'd be curious to see how area and experimental code is written, named, and organized.

Theron said on November 23, 2014

This sounds like a great approach. Additionally it's the same approach/procedure WordPress has need doing lately. When a completely new piece of functionality is introduced eg . Restful api. It's introduced and it's functionality is vetted and tested while it's a plugin. Then it's voted and rolled into core.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.