{"id":261110,"date":"2017-10-19T03:20:19","date_gmt":"2017-10-19T10:20:19","guid":{"rendered":"http:\/\/css-tricks.com\/?p=261110"},"modified":"2017-10-19T03:20:19","modified_gmt":"2017-10-19T10:20:19","slug":"5-tips-starting-front-end-refactor","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/5-tips-starting-front-end-refactor\/","title":{"rendered":"5 Tips for Starting a Front-End Refactor"},"content":{"rendered":"

For the last two weeks, I’ve been working on a really large refactor project at Gusto<\/a> and I realize that this is the first time that a project like this has gone smoothly for me. There haven’t been any kinks in the process, it took about as much time as I thought it would, and no-one appears to be mad at me. In fact, things have gone almost suspiciously<\/em> well. How did this happen and what was the issue?<\/p>\n

<\/p>\n

Well, we had a problem with how our CSS was organized. Some pages in our app loaded Bootstrap and some didn’t. Others were loading only our app styles and some weren’t loading the styles we served from our component library, a separate repo that includes all our forms, buttons, and variables, etc. This led to all sorts of design inconsistencies but most important of all it wasn’t clear how to write CSS in our app. Do the component library styles override Bootstrap? Does Bootstrap override the app styles? It was scary stuff.<\/p>\n

The goal was a rather complex one then. First, I needed to figure out how our styles were loaded in the app. Second, I wanted to remove Bootstrap from our node_modules<\/code> and make a new Sass file with all those styles. Third, I then had to remove all our Bootstrap styles and place them into the component library where we would be able to refactor every line of Bootstrap into each individual component (so all the styles for the Tabs.jsx<\/code> component was styled only by the Tabs.scss<\/code> file). All of this work should reduce the amount of CSS we write by thousands<\/em> of lines and generally make our codebase more readable and much more developer-friendly for the future.<\/p>\n

However, before I started I knew that everything would have to be extraordinarily organized because this would involve a big shakeup in terms of our codebase. There will be spreadsheets! There will be a single, neat and tidy pull request! Lo, and behold! There will be beautiful, glorious documentation for everyone to read.<\/p>\n

So here are some tips on making sure that big refactor projects go smoothly, based on my experience working on this large and complex codebase. Let’s begin!<\/p>\n

Tip #1: Gather as much data as you can<\/h3>\n

For this project, I needed to know a bunch of stuff beforehand, namely in the form of data. This data would then serve as metrics for success because if I could show that we could safely remove 90% of the CSS in the app then that’s a huge win that the rest of the team can celebrate.<\/p>\n

My favorite tool for refactoring CSS these days is Chrome’s Coverage tab in DevTools and that’s because it can show you just how much CSS is applied to any given page. Take a look here:<\/p>\n