Skip to Main Content

How a reusable code audit can optimize performance and design

Reusable Code Audit|benefits of reusable code example

It’s weird to call a process a perk, but our focus on reusable code is one of my favorite things about working at Table XI. Limiting ourselves to the absolute fewest number of components to build software is a challenge, and it’s one that’s made me a better developer.

It’s also a challenge that makes our products better

The more reusable your code, the more efficient your coding — and the more efficient your design and your software. By editing our design down to the functionality an application really needs, then coding those designs into reusable modules, we’re able to make better software. A simpler design is easier to navigate, a smaller codebase is easier to maintain, and the two together create an end-product that’s more coherent, that loads faster and that optimizes your performance.

See how we handle a full code audit — frontend, backend and infrastructure

The benefits of code reuse are catching on, but the best practices behind it definitely haven’t spread to every development team. Our frontend audits can catch opportunities to switch to reusable code, optimizing your website’s performance now and giving you a better sense of the benefits a full redesign would offer.

The many, many benefits of reusing code

In development, there’s a motto that “every line of code is a liability,” based loosely on the work of scientist Edsger Dijkstra. The more code you write, the more opportunities there are for errors, bugs that can muck up your software and waste your time.

That’s basically the meaning behind why reusable code is so important. If we can limit the code, we can limit the opportunities for things to go wrong. But that’s like the least exciting of the code reuse benefits. It doesn’t just make it easier to avoid mistakes — it makes it easier to grow.

A reusable code repository is a scalable code repository. Choose from the same elements, and you have a new page that fits right in with all your others. Bring on new people, and they can very quickly learn how to build within you system. Hand the code off to an entirely new team (like we did with LandscapeHub), and all you need is a little documentation for them to run with it.

Then there’s the speed. Smaller codebases load quicker, so reusing code is a direct way to optimize your site performance. Though the code is only part of it, that performance improvement is also thanks to reusing design elements — and all the benefits that come along with that.

Need help making your site even faster? An infrastructure audit can help.

How code reuse best practices support design best practices

The idea that there’s a code reuse vs. design reuse fight is kind of ridiculous. Design and development aren’t opponents — at Table XI we’re part of the same team. We both need to deliver our best, and so we work side-by side. Our UX designers can bounce ideas off of our frontend developers and see what’s possible, and our frontend developers get insight into the design. I personally enjoy collaborating with the designers, because it allows me to internalize their decisions. I know why they used certain colors and typography, and I can structure the frontend code to honor those objectives.

When we work like this, neither side has to compromise. One of the benefits of reusing code is that it also reinforces design best practices. Users can navigate a site better when there are repeatable elements that always do the same thing — like a button always using the same color. It creates a more cohesive, navigable site.

… And how code reuse helps developers stick to the design

This process also makes it much, much easier for a team to stick to a design. Writing reusable code for design elements is essentially like building a custom version of Bootstrap, a CSS, HTML and Javascript library of reusable styles people can use to build a site. The code itself guides you to follow the design rules, allowing you to grow pretty far before you need a designer to add new elements to the visual system.

Like I mentioned above, this is basically what we did for LandscapeHub. We knew the marketplace startup wanted to build an internal development team, so we made sure everything we designed was as ready to hand off as possible. When it was time to migrate to the new team, all we had to do was create a round of documentation on the benefits of the style guide and how to use it. Their developers loved it. They immediately felt confident about understanding the code. Everything was organized and reusable, so they could take ownership and start building.

A code reuse example to illustrate what we’re talking about (and maybe make your brain hurt)

If it’s hard for you to fully see the advantages of code reuse, it’s pretty easy to see the downsides of not doing it. For one of our frontend audits, I walked through a client’s design looking for one simple thing — error messages.

benefits of reusable code example

The client had a fair amount of forms for signing up, signing in and using the service, and pretty much each one used a different style to tell you when something was wrong. This isn’t just different font-sizes — we’re talking totally different colors, styles and locations. If you’re a user, there’s no consistency. Every time there’s an error, you have to search to find the message, instead of being able to rely on the visual shortcut of repeatable design.

How we define reusable code — and how we audit for it

When we’re trying to define code reusability, it’s not just about having elements repeat. In a frontend audit, we’re definitely looking at the actual UI to see how reusable the design system is. But on the other end, we’re going to be looking for whether that code is built in a reusable way. It’s totally possible — it’s actually pretty common — to have a reusable UI, but not code that takes advantage of it. You have to structure and organize your code to be reusable and scalable if that’s your goal. A simple site alone won’t get you there.

During a code audit, there are a few things that right away will let us know if your software supports code reuse. We look at how the stylesheets are organized, how they are included in the application and in what order they are pulled. The organization and order of the stylesheets are both good indicators of how the styles work together and whether they were written with reuse in mind.

We also look at individual styles within each stylesheet, paying attention to things like styling elements using IDs, nesting, variable usage and !important;. Styling elements using IDs is inherently not reusable, as IDs need to be unique. Each element can have only one ID and each page can have only one element with that ID. Using classes to style elements instead of IDs allows us to really optimize for reusable components and reduce the amount of specificity in our stylesheets.

Want to start visualizing your project risks? Download our free Software Risk Management template.

Download PDF

One of the biggest indicators of a difficult codebase is !important;. The !important; declaration overrides all specificity in the CSS. It forces you to stack cups — the only way to get past a !important; is with another !important; (or to refactor out the first !important;). Add enough, and you have a precarious tower.

Nesting styles too deeply also increases specificity and reduces reusability. Nesting HTML elements inside class selectors like .className > li > a creates a coupling between the markup and the stylesheets, making your app less predictable for developers working within it. Unpredictable applications make it difficult to know when a change might affect things it shouldn’t.

One way we combat this is by using variables for common items throughout the application, like colors, font sizes, typography, spacing, etc. Using variables makes it easy for us to make one global change and have it take effect across the application. Say all your buttons are blue and you want them to be green. With variables, changing this is as easy as changing one line of code. Applications that don’t use variables are almost always more challenging to update.

Creating style guides as code reuse tools

To help with these problems, our audit recommendations include advice for creating a living style guide in code. A living style guide will help keep your code cleaner (and keep you from having seven different error message styles accidentally).

At Table XI, we build our style guide at the start of the project. First we have the designers document their design system — the typefaces, color schemes, common UI elements, etc. Then we turn it into a living style guide in code.

Each language we develop in has a different styleguide generator, so the code reuse tools will change, but the process won’t. The style guide generator lets us document the visual elements within the code, which is the first step to styling elements in the browser. Once we lay that foundation, the style guide gives us a single place where everything is documented. When we need to know how to leverage elements within the system to build new features, the style guide is where we turn. It keeps us honest, so everything we’re building fits into the system, instead of going off on a bespoke path.

Bringing the advantages of code reusability to your software

A reusable code audit is a quick way to find all the ways your existing site can be optimized for performance and for usability. It’s not the same as a full UX audit — for that, you need to talk to real users. But it will let you add some UI best practices to your site, and find some optimizations for your code so it’s easier to navigate if you do want to make changes.

That said, successfully reusing code is really a multifaceted approach. You can’t just use a style guide and call it done. You need to create that style guide in collaboration with designers, and you need those designers to be thinking about a system of reusable components. That’s how you build a tight and consistent visual system, and an equally tight and consistent codebase.

At Table XI, we know our frontend code is done right when any developer can jump into it, understand what’s going on and add to it without any excess effort. That’s the gold standard, and it’s completely achievable. Really, most of the results that come out of our frontend audits are about simplifying your features and your code, not adding to them. If that’s something you think you could use, contact us!

Published by TXI in code audit

Let’s start a conversation

Let's shape your insights into experience-led data products together.