Fast abstract ↬

After analyzing CSS and its weaknesses, and administration giving a inexperienced mild to the refactoring challenge, it’s time to get to work. A group must agree on the interior code requirements and greatest practices, plan out the refactoring technique, and description particular person duties. We have to arrange a visible regression testing suite, and a upkeep plan to implement the brand new requirements and greatest practices sooner or later.

In Part 1, we’ve lined the uncomfortable side effects of low-quality CSS codebase on end-users, improvement groups, and administration. Sustaining, extending, and dealing with the low-quality codebase is troublesome and infrequently requires further time and sources. Earlier than citing the refactoring proposal to the administration and stakeholders, it may be helpful to again up the suggestion with some exhausting knowledge in regards to the codebase well being — not solely to persuade the administration division, but additionally have a measurable purpose for the refactoring course of.

Let’s assume that administration has authorized the CSS refactoring challenge. The event group has analyzed and pinpointed the weaknesses within the CSS codebase and has set goal targets for the refactor (file measurement, specificity, colour definitions, and so forth). On this article, we’ll take a deep dive into the refactoring course of itself, and canopy incremental refactoring technique, visible regression testing, and sustaining the refactored codebase.

Preparation And Planning

Earlier than beginning the refactoring course of, the group must go over the codebase points and CSS health audit data (CSS file measurement, selector complexity, duplicated properties, and declarations, and so forth.) and talk about particular person points about easy methods to method them and what challenges to count on. These points and challenges are particular to the codebase and may make the refactoring course of or testing troublesome. As concluded within the previous article, it’s necessary to ascertain inner guidelines and codebase requirements and maintain them documented to ensure that the group is on the identical web page and has a extra unified and standardized method to refactoring.

The group additionally wants to stipulate the person refactoring duties and set the deadlines for finishing the refactoring challenge, taking into consideration present duties and ensuring that refactoring challenge doesn’t forestall the group from addressing pressing duties or engaged on deliberate options. Earlier than estimating the time period and workload of the refactoring challenge, the group must seek the advice of with the administration in regards to the short-term plans and alter their estimates and workload based mostly on the deliberate options and common upkeep procedures.

Not like common options and bug fixes, the refactoring course of yields little to no seen and measurable modifications on the entrance finish, and administration can not maintain monitor of the progress on their very own. It’s necessary to ascertain clear communication to maintain the administration and different challenge stakeholders up to date on the refactoring progress and outcomes. On-line collaborative workspace instruments like Miro or MURAL may also be used for efficient communication and collaboration between the group members and administration, in addition to a fast and easy job administration device.

Christoph Reinartz identified the significance of transparency and clear communication whereas the team at trivago was engaged on the CSS refactoring challenge.

“Communication and clearly making the progress and any upcoming points seen to the entire firm have been our solely weapon. We determined to construct up a quite simple Kanban board, established a challenge stand-up and a challenge Slack channel, and stored administration and the corporate up-to-date by way of our inner social forged community.”

Simple, clear and effective Kanban board used for large scale CSS refactoring at trivago. (Image by trivago)

Easy, clear and efficient Kanban board used for big scale CSS refactoring at trivago. (Picture by trivago) (Large preview)

Essentially the most essential factor of planning the refactoring course of is to maintain the CSS refactoring job scope as small as potential. This makes the duties extra manageable, and simpler to check and combine.

Harry Roberts refers to those duties as “refactoring tunnels”. For instance, refactoring the complete codebase to comply with the BEM methodology unexpectedly can yield an enormous enchancment to the codebase and the event course of. This may look like a easy search-and-replace job at first. Nevertheless, this job impacts all components on each web page (excessive scope) and the group can not “see the sunshine on the finish of the tunnel” immediately; numerous issues can break within the course of and surprising points can decelerate the progress and nobody can inform when the duty goes to be completed. The group can spend days or even weeks engaged on it and threat hitting a wall, accumulate further technical debt, or making the codebase even much less wholesome. The group finally ends up both giving up on the duty of beginning over, losing time and sources within the course of.

In contrast, bettering simply the navigation part CSS is a smaller scope job and is far more manageable and doable. It is usually simpler to check and confirm. This job could be executed in a number of days. Even with potential points and challenges that decelerate the duty, there’s a excessive likelihood of success. The group can at all times “see the tip of the tunnel” whereas they’re engaged on the duty as a result of they know the duty shall be accomplished as soon as the part has been refactored and all points associated to the part have been fastened.

Lastly, the group must agree on the refactoring technique and regression testing technique. That is the place the refactoring course of will get difficult — refactoring must be as streamlined as potential and shouldn’t introduce any regressions or bugs.

Let’s dive into one of many only CSS refactoring methods and see how we will use it to enhance the codebase shortly and successfully.

Extra after bounce! Proceed studying beneath ↓

Incremental Refactoring Technique

Refactoring is a difficult course of that’s far more advanced than merely deleting the legacy code and changing it with the refactored code. There’s additionally the matter of integrating the refactored codebase with the legacy codebase and avoiding regressions, unintended code deletions, stopping stylesheet conflicts, and so forth. To keep away from these points, I might advocate utilizing an incremental (or granular) refactoring technique.

In my view, this is likely one of the most secure, most sensible, and most beneficial CSS refactoring methods I’ve come throughout to date. Harry Roberts has outlined this strategy in 2017. and it has been my private go-to CSS refactoring technique since I first heard about it.

Let’s go over this technique step-by-step.

Step 1: Decide A Element And Develop It In Isolation

This technique depends on particular person duties having low scope, which means that we should always refactor the challenge part by part. It’s beneficial to begin with low-scope duties (particular person elements) after which transfer onto higher-scoped duties (international types).

Relying on the challenge construction and CSS selectors, particular person part types include a mixture of part (class) types and international (wide-ranging factor) types. Each part types and international types could be the supply of the codebase points and may should be refactored.

Let’s check out the extra frequent CSS codebase points which might have an effect on a single part. Element (class) selectors could be too advanced, troublesome to reuse, or can have excessive specificity and implement the precise markup or construction. World (factor) selectors could be grasping and leak undesirable types into a number of elements which should be undone with high-specificity part selectors.

Starting state of the CSS and HTML codebase that we want to refactor. Card component markup consists of multiple HTML elements. Card component styles consist of a combination of class selector styles and global element selector styles.

Beginning state of the CSS and HTML codebase that we need to refactor. Card part markup consists of a number of HTML components. Card part types include a mixture of sophistication selector types and international factor selector types. (Large preview)

After selecting a part to refactor (a lower-scoped job), we have to develop it in an remoted setting away from the legacy code, its weaknesses, and conflicting selectors. That is additionally alternative to enhance the HTML markup, take away pointless nestings, use higher CSS class names, use ARIA attributes, and so forth.

You don’t need to exit of your approach to arrange a complete construct system for this, you possibly can even use CodePen to rebuild the person elements. To keep away from conflicts with the legacy class names and to separate the refactored code from the legacy code extra clearly, we’ll use an rf- prefix on CSS class identify selectors.

Building refactored Card component CSS and Markup in isolation.

Constructing refactored Card part CSS and Markup in isolation. (Large preview)

Step 2: Merge With The Legacy Codebase And Repair Bugs

As soon as we’ve completed rebuilding the part in an remoted setting, we have to substitute the legacy HTML markup with refactored markup (new HTML construction, class names, attributes, and so forth.) and add the refactored part CSS alongside the legacy CSS.

We don’t need to act too rapidly and take away legacy types immediately. By making too many modifications concurrently, we’ll lose monitor of the problems that may occur as a result of conflicting codebases and a number of modifications. For now, let’s substitute the markup and add refactored CSS to the prevailing codebase and see what occurs. Remember that refactored CSS ought to have the .rf- prefix of their class names to forestall conflicts with the legacy codebase.

Replacing the legacy Card markup with refactored markup and adding refactored Card CSS alongside legacy styles. Legacy component and global styles apply unwanted side-effects due to the wide-reaching global or element selectors.

Changing the legacy Card markup with refactored markup and including refactored Card CSS alongside legacy types. Legacy part and international types apply undesirable side-effects as a result of wide-reaching international or factor selectors. (Large preview)

Legacy part CSS and international types may cause surprising side-effects and leak undesirable types into the refactored part. Refactored codebase could be lacking the defective CSS which was required to undo these side-effects. On account of these types having a wider attain and presumably affecting different elements, we can not merely edit the problematic code immediately. We have to use a special method to deal with these conflicts.

We have to create a separate CSS file, which we will identify overrides.css or defend.css which can comprise hacky, high-specificity code that combats the undesirable leaked types from the legacy codebase.

overrides.css which can comprise high-specificity selectors which ensure that the refactored codebase works with the legacy codebase. That is solely a short lived file and it will likely be eliminated as soon as the legacy code is deleted. For now, add the high-specificity type overrides to unset the types utilized by legacy types and take a look at if all the pieces is working as anticipated.

We are adding overrides.css to combat the unwanted side-effects. This file contains high-specificity code that overrides the legacy styles.

We’re including overrides.css to fight the undesirable side-effects. This file accommodates high-specificity code that overrides the legacy types. (Large preview)

For those who discover any points, test if the refactored part is lacking any types by going again to the remoted setting or if some other types are leaking into the part and should be overridden. If the part appears to be like and works as anticipated after including these overrides, take away the legacy code for the refactored part and test if any points occur. Take away associated hacky code from overrides.css and take a look at once more.

Legacy Card component styles can now be safely removed, alongside with (some) styles from overrrides.css which helped combat the side-effects from those selectors. However, global CSS selectors may still apply unwanted side-effects so we cannot completely remove this file until we’ve refactored global styles also.

Legacy Card part types can now be safely eliminated, alongside with (some) types from overrrides.css which helped fight the side-effects from these selectors. Nevertheless, international CSS selectors should apply undesirable side-effects so we can not utterly take away this file till we’ve refactored international types additionally. (Large preview)

Relying on the case, you most likely gained’t be capable of take away each override immediately. For instance, if the problem lies inside a worldwide factor selector which leaks types into different elements that additionally should be refactored. For these instances, we gained’t threat increasing the scope of the duty and the pull request however reasonably wait till all elements have been refactored and deal with the high-scope duties after we’ve eliminated the identical type dependency from all different elements.

In a approach, you possibly can deal with the overrides.css file as your makeshift TODO checklist for refactoring grasping and wide-reaching factor selectors. You must also take into account updating the duty board to incorporate the newly uncovered points. Be sure that so as to add helpful feedback within the overrides.css file so different group members are on the identical web page and immediately know why the override has been utilized and in response to which selector.

/* overrides.css */
/* Resets dimensions enforced by ".sidebar > div" in "sidebar.css" */
.sidebar > .card 
  min-width: 0;

/* Resets font measurement enforced by ".hero-container" in "hero.css"*/
  font-size: 18px;

Step 3: Take a look at, Merge And Repeat

As soon as the refactored part has been efficiently built-in with the legacy codebase, create a Pull Request and run an automatic visible regression take a look at to catch any points that may have gone unnoticed and repair them earlier than merging them into one of many important git branches. Visible regression testing could be handled because the final line of protection earlier than merging the person pull requests. We’ll cowl visible regression testing in additional element in one of many upcoming sections of this text.

Now rinse and repeat these three steps till the codebase has been refactored and overrides.css is empty and could be safely eliminated.

Step 4: Transferring From Elements To World Types

Let’s assume that we’ve refactored all particular person low-scoped elements and all that’s left within the overrides.css file are associated to international wide-reaching factor selectors. This can be a very sensible case, talking from the expertise, as many CSS points are attributable to wide-reaching factor selectors leaking types into a number of elements.

By tackling the person elements first and shielding them from the worldwide CSS side-effects utilizing overrides.css file, we’ve made these higher-scoped duties far more manageable and fewer dangerous to do. We are able to transfer onto refactoring international CSS types extra safely than earlier than and take away duplicated types from the person elements and changing them with normal factor types and utilities — buttons, hyperlinks, pictures, containers, inputs, grids, and so forth. By doing so, we’re going to incrementally take away the code from our makeshift TODO overrides.css file and duplicated code repeated in a number of elements.

Let’s apply the identical three steps of the incremental refactoring technique, beginning by growing and testing the types in isolation.

Refactoring global styles in isolation. If these global styles are using element selectors without any special markup or class name applied, then markup won’t change and only the refactored CSS needs to be moved to the codebase.

Refactoring international types in isolation. If these international types are utilizing factor selectors with none particular markup or class identify utilized, then markup gained’t change and solely the refactored CSS must be moved to the codebase. (Large preview)

Subsequent, we have to add the refactored international types to the codebase. We’d encounter the identical points when merging the 2 codebases and we will add the required overrides within the overrides.css. Nevertheless, this time, we will count on that as we’re regularly eradicating legacy types, we may also be capable of regularly take away overrides that we’ve launched to fight these undesirable side-effects.

The draw back of growing elements in isolation could be present in factor types which are shared between a number of elements — type information components like buttons, inputs, headings, and so forth. When growing these in isolation from the legacy codebase, we don’t have entry to the legacy type information. Moreover, we don’t need to create these dependencies between the legacy codebase and refactored codebase.

That’s the reason it’s simpler to take away the duplicated code blocks and transfer these types into separate, extra normal type information elements and selectors in a while. It permits us to handle these modifications proper on the finish and with the decrease threat as we’re working with a a lot more healthy and constant codebase, as a substitute of the messy, inconsistent, and buggy legacy codebase. After all, any unintended side-effects and bugs can nonetheless occur and these must be caught with the visible regression testing instruments which we’ll cowl in one of many following sections of the article.

Merging the refactored global CSS with the codebase and updating overrides.css to remove unwanted side-effects of the legacy codebase.

Merging the refactored international CSS with the codebase and updating overrides.css to take away undesirable side-effects of the legacy codebase. (Large preview)

When the codebase has been utterly refactored and we’ve eliminated all makeshift TODO objects from the overrides.css file, we will safely take away it and we’re left with the refactored and improved CSS codebase.

Removing legacy global styles and overrides.css once the codebase has been completely refactored.

Eradicating legacy international types and overrides.css as soon as the codebase has been utterly refactored. (Large preview)

Incremental CSS Refactoring Instance

Let’s use the incremental refactoring technique to refactor a easy web page that consists of a title factor and two card elements in a grid part. Every card factor consists of a picture, title, subtitle, description, and a button and is positioned in a 2-column grid with horizontal and vertical spacing.

See the Pen [Refactoring CSS — example 1]( by Adrian Bece.

See the Pen Refactoring CSS — example 1 by Adrian Bece.

As you possibly can see, we’ve a suboptimal CSS codebase with numerous specificity points, overrides, duplicated code, and a few instances of undoing types.

h1, h2 
    margin-top: 0;
    margin-bottom: 0.75em;
    line-height: 1.3;
    font-size: 2.5em;
    font-family: serif;

/* ... */

.card h2 
  font-family: Helvetica, Arial, sans-serif;
  margin-bottom: 0.5em;
  line-height: preliminary;
  font-size: 1.5em;

The .card part additionally makes use of excessive specificity selectors which enforces a particular HTML construction and permits types to leak into different components inside the cardboard elements.

/* Ingredient must comply with this particular HTML construction to have these types utilized */
.card h2 > small 
 /* ... */

/* These types will leak into all div components in a card part */
.card div 
  padding: 2em 1.5em 1em;

/* These types will leak into all p components in a card part */
.card p 
  font-size: 0.9em;
  margin-top: 0;

We’ll begin with the bottom scoped and topmost youngsters elements, so let’s refactor the cardboard part which is the topmost little one of the web page, i.e. the cardboard part is a toddler of the grid part. We’ll develop the cardboard part in isolation and use the agreed requirements and greatest practices.

We’ll use BEM to switch the grasping wide-reaching selectors with easy class selectors and use CSS customized properties to switch the inconsistent, hard-coded inline colour values. We’ll additionally add some CSS to assist us develop the part, which we gained’t copy to the prevailing codebase.

See the Pen [Refactoring CSS — example 2 (isolated card component)]( by Adrian Bece.

See the Pen Refactoring CSS — example 2 (isolated card component) by Adrian Bece.

We’re utilizing the rf- prefix for the brand new CSS lessons so we will keep away from class identify conflicts and differentiate the refactored types from legacy types for higher code group and less complicated debugging. This may also enable us to maintain monitor of the refactoring progress.

  colour: var(--color-text);
  background: var(--color-background);

  margin: 0;

  line-height: 1.3;
  margin-top: 0;
  margin-bottom: 0.5em;

We’re going to substitute the legacy markup with the refactored markup, and add the refactored types to the CSS codebase. We aren’t going to take away the legacy types simply but. We have to test if any types from different legacy selectors have leaked into the refactored part.

Because of the points with international wide-ranging selectors, we’ve some undesirable type overrides leaking into the refactored part — title font properties have been reset and font measurement inside the cardboard part has modified.

  /* ... */
  font-size: 24px;

h1, h2 
    /* ... */
    font-size: 2.5em;
    font-family: Georgia, "Instances New Roman", Instances, serif;

See the Pen [Refactoring CSS — example 3 (merge legacy and refactor)]( by Adrian Bece.

See the Pen Refactoring CSS — example 3 (merge legacy and refactor) by Adrian Bece.

We have to add type overrides to overrides.css to take away the undesirable side-effects from different selectors. We’re additionally going to touch upon every override so we all know which selector has brought about the problem.

/* Prevents .grid font-size override  */
  font-size: 16px;

/* Prevents h1, h2 font override  */
  font-family: Helvetica, Arial, sans-serif;
  font-size: 1.5em;

We now know that we’re going to need to refactor the .grid part and international h1, h2 selector in some unspecified time in the future. Because of this we will deal with it as a TODO checklist – these leaked types may cause points in different elements, they’re objectively defective, and are making use of types which are being reset within the majority of use-cases.

See the Pen [Refactoring CSS — example 4 (adding overrides.css)]( by Adrian Bece.

See the Pen Refactoring CSS — example 4 (adding overrides.css) by Adrian Bece.

Let’s take away the legacy .card types from the challenge and see if all the pieces appears to be like alright. We are able to test if we will take away any types from overrides.css, nonetheless, we all know immediately that not one of the overrides are associated to legacy card part types, however different elements and factor selectors.

See the Pen [Refactoring CSS — example 5 (Removing legacy component styles)]( by Adrian Bece.

See the Pen Refactoring CSS — example 5 (Removing legacy component styles) by Adrian Bece.

Now that the cardboard part has been refactored, let’s test our makeshift TODO checklist and see what to deal with subsequent. We now have a selection between:

  • Refactor the grid part — decrease scope (quick tunnel),
  • Refactor international types — greater scope (longer tunnel).

We’ll go along with the bottom scope part, the grid part on this case, and apply the identical method. We’ll begin by growing the grid part in isolation. We are able to use the cardboard part markup for testing, card part types gained’t have an effect on the grid and gained’t assist us develop the part, so we will go away them out of the remoted part for a less complicated CSS markup.

See the Pen [Refactoring CSS — example 6 (refactoring grid component)]( by Adrian Bece.

See the Pen Refactoring CSS — example 6 (refactoring grid component) by Adrian Bece.

Let’s substitute the grid HTML markup with the refactored markup and add the refactored types to the CSS codebase and test if we have to add any types to overrides.css to mitigate any stylesheet conflicts or leaked types.

See the Pen [Refactoring CSS — example 7 (merged grid component, updated overrides.css, removed styles)]( by Adrian Bece.

See the Pen Refactoring CSS — example 7 (merged grid component, updated overrides.css, removed styles) by Adrian Bece.

We are able to see that no new points appeared, so we will proceed with eradicating the legacy .grid types. Let’s additionally test if overrides.css accommodates any types which are utilized for the legacy .grid selector.

/* Reset .grid font-size override */
  font-size: 16px;

Because of this it’s helpful to doc the override guidelines. We are able to safely take away this selector and transfer it onto the final merchandise in our makeshift TODO checklist — heading factor selectors. We’re going to undergo the identical steps once more — we’ll create a refactored markup in isolation, substitute the HTML markup and add the refactored types to the stylesheet.

<h1 class="rf-title rf-title--size-regular rf-title--spacing-regular">Featured galleries</h1>
   font-family: Georgia, "Instances New Roman", Instances, serif;

    line-height: 1.3;
    font-size: 2.5em;

    margin-top: 0;
    margin-bottom: 0.75em;

We’ll test if there are any points and ensure that no new points have been launched by the up to date markup and stylesheet and we’ll take away the legacy h1, h2 selector from the stylesheet. Lastly, we’re going to test overrides.css and take away the types associated to the legacy factor selector.

See the Pen [Refactoring CSS — example 8 (element selectors)]( by Adrian Bece.

See the Pen Refactoring CSS — example 8 (element selectors) by Adrian Bece.

The overrides.css is now empty and we’ve refactored the cardboard, grid, and title elements in our challenge. Our codebase is far more more healthy and constant in comparison with the place to begin — we will add components to the grid part and new title variations with out having to undo the leaked types.

Nevertheless, there are a number of tweaks we will do to enhance our codebase. As we’ve developed the elements in isolation, we’ve most likely re-built the identical type information elements a number of occasions and created some duplicated code. For instance, a button is a mode information part and we’ve scoped these types to a card part.

/* Refactored button types scoped to a part */
  colour: var(--color-text-negative);
  background-color: var(--color-cta);
  padding: 1em;
  show: flex;
  justify-content: middle;
  text-decoration: none;
  text-transform: uppercase;
  letter-spacing: 0.05em;
  font-weight: 600;

If some other part is utilizing the identical button types, it signifies that we’re going to jot down the identical types every time we develop them in isolation. We are able to refactor these duplicates right into a separate .button part and substitute the duplicated scoped types with normal type information types. Nevertheless, we have already got a legacy .button selector which must be refactored, so we’re additionally in a position to take away the legacy button selector.

Regardless that we’re transferring onto refactoring greater scoped components, the codebase is way more healthy and constant in comparison with the place to begin, so the chance is decrease and the duty is far more doable. We additionally don’t have to fret that the modifications within the topmost little one elements will override any modifications to the final selector.

/* Defective legacy button types */
  border: 0;
  show: block;
  max-width: 200px !necessary;
  text-align: middle;
  margin: 1em auto;
  padding: 1em;
  text-transform: uppercase;
  letter-spacing: 0.05em;
  cursor: pointer;
  font-weight: daring;
  text-decoration: none;

  max-width: none !necessary;
  margin-bottom: 0;
  colour: #fff;
  background-color: darkred;
  margin-top: 1em;

We are able to use the identical incremental method to the We’re going to rebuild the button part in isolation, replace the markup, and add the refactored types to the stylesheet. We’re going to do a fast test for stylesheet conflicts and bugs, discover that nothing has modified, and take away the legacy button markup and the component-scope button types.

  show: flex;
  justify-content: middle;
  text-decoration: none;
  text-transform: uppercase;
  letter-spacing: 0.05em;
  font-weight: 600;

   padding: 1em;

  colour: var(--color-text-negative);
  background-color: var(--color-cta);
/* Earlier than - button types scoped to a card part */
<a category="rf-card__link" href="#">View gallery</a>

/* After - Basic types from a button part */
<a category="rf-button rf-button--regular rf-button--cta" href="#">View gallery</a>

See the Pen [Refactoring CSS — example 9 (final result)]( by Adrian Bece.

See the Pen Refactoring CSS — example 9 (final result) by Adrian Bece.

As soon as the refactoring challenge has been accomplished, we will use search-and-replace to wash up the rf- prefixes within the codebase and deal with the prevailing codebase as the brand new commonplace. That approach, extending the codebase gained’t introduce naming inconsistencies or drive the rf- prefix naming that might trigger points for any future refactors.

Testing And Avoiding Regressions

Whatever the refactor duties’ scope measurement and the way effectively the group follows the incremental refactoring technique steps, bugs and regressions can occur. Ideally, We need to keep away from introducing points and regressions within the codebase — conflicting types, lacking types, incorrect markup, leaked types from different components, and so forth.

Utilizing automated visible regression testing instruments like Percy or Chromatic on a Pull Request stage can pace up testing, enable builders to handle regressions shortly and early, and ensure that the bugs don’t find yourself on the reside website. These instruments can take screenshots of particular person pages and elements and examine modifications in type and format and notify builders of any visible modifications that may occur attributable to modifications within the markup or CSS.

Because the CSS refactor course of shouldn’t lead to any visible modifications in traditional instances and relying on the duty and points within the legacy codebase, the visible regression testing course of can doubtlessly be easy as checking if any visible modifications occurred in any respect and checking if these modifications have been intentional or unintentional.

Visual regression test example in Chromatic. Dimensions for this specific button variation have been unintentionally changed when the button component has been refactored. This issue has been caught when Pull Request has been created, so developers were able to address this issue early.

Visible regression take a look at instance in Chromatic. Dimensions for this particular button variation have been unintentionally modified when the button part has been refactored. This subject has been caught when Pull Request has been created, so builders have been in a position to tackle this subject early. (Large preview)

Relying on the challenge, testing instruments don’t should be advanced or subtle to be efficient. Whereas engaged on refactoring the Sundance Institute’s CSS codebase, the event group used a easy static type information web page generated by Jekyll to check the refactored elements.

“One unintended consequence of executing the refactor in abstraction on a Jekyll occasion was that we may now publish it to Github pages as a living style guide. This has turn out to be a useful useful resource for our dev group and for exterior distributors to reference.”

As soon as the CSS refactor duties have been accomplished and the refactored code is prepared for manufacturing, the group also can take into account doing an A/B take a look at to test the impact of the refactored codebase on customers. For instance, if the purpose of the refactoring course of was to cut back the general CSS file measurement, the A/B take a look at can doubtlessly yield vital enhancements for cell customers, and these outcomes may also be useful to challenge stakeholders and administration. That’s precisely how the team at Trivago approached the deployment of their large-scale refactoring challenge.

“(…) we have been in a position to launch the technical migration as an A/B Take a look at. We examined the migration for one week, with constructive outcomes on cell gadgets the place mobile-first paid out and accepted the migration after solely 4 weeks.”

Protecting Observe Of Refactoring Progress

Kanban board, GitHub points, GitHub challenge board, and commonplace challenge administration instruments can do an excellent job of maintaining monitor of the refactoring progress. Nevertheless, relying on the instruments and the way the challenge is organized, it might be troublesome to estimate the progress on a per-page foundation or do a fast test on which elements should be refactored.

That is the place our .rf-prefixed CSS lessons are available. Harry Roberts has talked in regards to the benefits of using the prefix intimately. The underside line is — not solely do these lessons enable builders to clearly separate the refactored CSS codebase from the legacy codebase, but additionally to shortly present the progress to the challenge managers and different challenge stakeholders on a per-page foundation.

For instance, administration could resolve to check the consequences of the refactored codebase early by deploying solely the refactored homepage code and they might need to know when the homepage elements shall be refactored and prepared for A/B testing.

As a substitute of losing a while evaluating the homepage elements with the out there duties on the Kanban board, builders can simply briefly add the next types to spotlight the refactored elements which have the rf- prefix of their class names, and the elements that should be refactored. That approach, they will reorganize the duties and prioritize refactoring homepage elements.

/* Highlights all refactored elements */
  define: 5px stable inexperienced;

/* Highlights all elements that havent been refactored */

physique *:not([class]) 
  define: 5px stable purple;

Previous example of refactored card component with temporary highlight code added. Components that have been refactored are highlighted with the green outline, while components that may need to be refactored are highlighted with the red outline.

Earlier instance of refactored card part with momentary spotlight code added. Elements which were refactored are highlighted with the inexperienced define, whereas elements which will should be refactored are highlighted with the purple define. (Large preview)

Sustaining The Refactored Codebase

After the refactoring challenge has been accomplished, the group wants to verify to keep up the codebase well being for the foreseeable future — new options shall be developed, some new options may even be rushed and produce technical debt, numerous bugfixes may also be developed, and so forth. All in all, the event group must ensure that the codebase well being stays steady so long as they’re in command of the codebase.

Technical debt which may end up in doubtlessly defective CSS code must be remoted, documented, and applied in a separate CSS file which is usually named as disgrace.css.

It’s necessary to doc the foundations and greatest practices that have been established and utilized throughout the refactoring initiatives. Having these guidelines in writing permits for standardized code evaluations, sooner challenge onboarding for brand spanking new group members, simpler challenge handoff, and so forth.

Among the guidelines and greatest practices may also be enforced and documented with automated code-checking instruments like stylelint. Andrey Sitnik, the writer of widely-used CSS improvement instruments like PostCSS and Autoprefixer, has famous how computerized linting instruments could make code evaluations and onboarding easier and less stressful.

“Nevertheless, computerized linting will not be the one purpose to undertake Stylelint in your challenge. It may be extraordinarily useful for onboarding new builders on the group: numerous time (and nerves!) are wasted on code evaluations till junior builders are totally conscious of accepted code requirements and greatest practices. Stylelint could make this course of a lot much less nerve-racking for everybody.”

Moreover, the group can create a Pull Request template and embody the guidelines of requirements and greatest practices and a hyperlink to the challenge code guidelines doc in order that the builders making the Pull Request can test the code themselves and ensure that it follows the agreed requirements and greatest practices.


Incremental refactoring technique is likely one of the most secure and most beneficial approaches with regards to refactoring CSS. The event group must refactor the codebase part by part to make sure that the duties have a low scope and are manageable. Particular person elements should be then developed in isolation — away from the defective code — after which merged with the prevailing codebase. The problems which will come up from the conflicting codebases could be solved by including a short lived CSS file that accommodates all the required overrides to take away the conflicts in CSS types. After that, legacy code for the goal part could be eliminated and the method continues till all elements have been refactored and till the momentary CSS file which accommodates the overrides is empty.

Visible regression testing instruments like Percy and Chromatic can be utilized for testing and to detect any regressions and undesirable modifications on the Pull Request stage, so builders can repair these points earlier than the refactored code is deployed to the reside website.

Builders can use A/B testing and use monitoring instruments to ensure that the refactoring doesn’t negatively have an effect on efficiency and consumer expertise earlier than lastly launching the refactored challenge on a reside website. Builders may also want to make sure that the agreed requirements and greatest practices are used on the challenge continues to keep up the codebase well being and high quality sooner or later.


Smashing Editorial(vf, yk, il)

Source link

Translate »