3 Essential Tips for Refactoring CSS Without Losing Your Mind
3 Essential Tips for Refactoring CSS Without Losing Your Mind
We sat down with CSS Wizardry's Harry Roberts for a Shopify Partner Session webinar, where we chatted about the importance and challenges of refactoring legacy CSS.
Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
Working with legacy code can be tremendously cumbersome for even the most seasoned web developer.
From eye-straining syntax to performance issues on a global scale, unruly code can be one of the biggest pain points you can encounter when working on a new client’s website. Luckily, refactoring offers an option for escaping the abyss of jumbled code.
If you’ve never done it before, refactoring is the process of restructuring an existing code base in such a way that it does not alter the external behavior of the code, yet improves its internal structure.
A few weeks ago, we sat down with CSS Wizardry's Harry Roberts for a Shopify Partner Session webinar, where we chatted about the importance and challenges of refactoring legacy CSS. Harry walked us through his process and offered some valuable advice for developers just getting started with refactoring. You can watch the full webinar recording here:
During his talk, Harry also shared a variety of tips to keep in mind when approaching a refactoring project. We’ve compiled some of them here to offer you the advice needed to start refactoring CSS without losing your mind.
1. Understand When It's Time to Refactor
While it’s important to understand how to go about refactoring a code base, it’s equally crucial to understand when it’s appropriate to do so. Refactoring can be a very human resource-heavy process, which can require countless hours sifting through every feature of your, or your client’s, website or applications.
While Harry firmly states that “in one way or another, we should always be refactoring our code on an ongoing basis,” he also admits that there are a few instances that always necessitate refactoring. His litmus test for identifying these types of situations is based on the following three variables:
- If the projected cost of maintenance is higher than rewriting — The purpose of refactoring is to remove unnecessary code to increase performance and reduce cost. If your proposed process offers a cheaper alternative to maintaining the existing code base, it’s beneficial for you to refactor now before those maintenance costs grow even larger.
- If the current version of your feature is hindering performance — If the current version is slowing down your website, it is a clear indication that it is time for you to look at your existing code infrastructure.
- If the new version of your feature or refactored code provides tangible benefit — This is the opposite to the aforementioned line, but is nonetheless important to consider. Even if your existing version isn’t overly problematic, there may still be some potential benefits that arise from tidying up CSS. Take the time to review and see if anything has slipped through the cracks.
2. Understand When It Isn't Time to Refactor
There are many instances when refactoring just isn’t the right solution for you to pursue. Given the high cost and effort associated with refactoring, it’s especially important to understand when it may actually be the more costly option.
Below, are some of Harry’s tips for deciding whether or not you need to refactor.
- If you’re not actually being slowed down by something — If something isn’t proving problematic for your, or your client’s website, application, or business, then it probably isn’t worthwhile to refactor just yet.
- If it’s something that can be captured by a rewrite later on — If your client is aware that in a few months they are going to be rewriting their entire site, it isn’t really worthwhile to refactor the code base at this moment, if the work is going to be deleted down the line.
- If a rewrite is a better solution than refactoring — There are some projects where the code base is so painful that rewriting the entire CSS from scratch is actually the smarter option than refactoring the existing code.
3. Understand the Benefits of Refactoring
Some clients may be hesitant about hiring you to refactor their website’s CSS due to a lack of understanding of what refactoring actually accomplishes. This can be especially true for those less tech-savvy clients, who may see refactoring as simply housekeeping for their existing website. It’s important in these situations that you’re able to clearly communicate the benefits refactoring can have on their website or web application.
If you find yourself faced with a skeptical client, make sure to communicate the positive impacts refactoring can have for their business. A few examples you can share include:
- Increase readability and ease of use for developers — By nature of the refactoring process, you’ll be reducing the complexity of your CSS system. This, in turn, will make it easier for other developers to access, read, and update your code. This can be especially important for companies onboarding new developers or working within larger development teams.
- Fewer bugs, enhanced performance, and a better user experience — The performance benefits from refactoring are well-known. By tidying your code, your web application or website will see near immediate enhancements, which will result in an overall better experience for your end users.
- Helps remove technical debt and save money — Poor code structure requires constant maintenance, and often means developers are spending more time working in the code than is actually required. By refactoring, you’ll lower your technical debt internally, which can translate into financial savings — something every client wants to hear.
Start Refactoring CSS Without Losing Your Mind
If you’re looking to learn more about the refactoring process, make sure to watch our recording of Harry’s webinar.
Published at DZone with permission of Courtney Symons , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.