A CSS opportunity
STEP 0: Intro/the part you can skip
As a lead, you need to spot opportunities and see how you catch them before they drift away. One of these times came when I recruited a new staff member that had a big passion for CSS.
“The CSS is terrible” he cried, and instead of fixing a small bug, asked to refactor it. Since the main role of my job is to understand people, I give him an OK, ignoring the angry looks from the QA.
“But there will be no side effects”, I asked. And he assured me that there will be none.
“don’t worry. His code will never reach production”, I whispered to the QA, calming her down. And yes, the programmer learned a lesson in modesty.
But modesty is not worth a post. This post comes later on, after I asked him to suggest an approach to refactor all the CSS in the SPA. A challenge he was happy to grab.
For all its flexibility and simplicity, CSS itself has some fundamental issues that allow developers to write poor-quality code in the first place… Before deciding to propose a granular codebase refactor or a full CSS rewrite, we need to understand the issues with the current codebase so we can avoid them in the future and have measurable data for the process.
Refactoring CSS: Introduction (Part 1)
STEP 1: The research
CSS patterns have their history. In the beginning, there was one big mess. Then came some more mess. And there still is. But all over the years, it shifted between the same concerns:
- How to manage and reuse CSS
- How to make the HTML shorter/more readable.
- How to handle the strange desires of the product and still keep the CSS sane.
CSS approached moved from atomic to declarative, and stable with two main patterns:
So our growing CSS master had been asked to give a lecture on CSS history and patterns. And to show a demo of before and after refactoring one of our components. This exposed all the staff members to the subject, showing them the different factors and considerations. But most of all, prepare their mindset for the upcoming changes.
STEP 2: The POC
“Very nice”, I told him at the end of the lecture. “But we either we do it perfectly, or not at all”.
Eager to spark, he started refactoring. Sworn only to create a guideline and examples for common cases for the rest. This time my job was to block him from rushing forward.
STEP 3: Knowledge sharing
“Now you take the lead”, I told him.
He was asked to provide each member with a specific component to refactor. His role was to assist us in the process, and see that we follow the new conventions.
The other members were to have a sheet of paper by their side, write comments and document thoughts along the way.
STEP 4: Brainstorming
This brought us to the most important part of the process: brainstorming. In which we argued, thrown buzzwords, pointed to examples and shouted at each other. well, except for the last one.
In the end, even if we didn’t agree about every bit and byte, we all know where we are headed and what are the reasons for every decision. Each member felt connected to the new approach, and had a clear understanding of it.
STEP 5: Internalization
So we sat and refactored some more components, under the supervision of the growing CSS master, until making the new coding standard unstudied and fluent to us all.
Only then I gave him a green light to rush forward, enabling him to finish the process while doing the thing he loved most: write beautiful CSS.
Summary
- One month’s work of one staff member.
- Three working days of the others.
- Peeling six years of CSS.
- One BEM / SMACSS style guide.
- Three hundred twenty-seven files changed.
- Reduce the CSS file size by 80%.
- Reduce the number of CSS selectors from ~8200 to ~1800.
- Remove hundreds of unnecessary nested HTML attributes.
- Get rid of LESS and some more libraries.
- Start using grid’s, flex’s & variables
- Creating a truly responsive app.
And some side effects:
- A team that feels involved, heard and up to date.
- A satisfy member that made a big impact and got credit for it.
- A QA member that’s just waited for the opportunity to hit me with a bat.