Refactoring CSS without Losing Your Mind

WEBEXPO | By Harry Roberts

Reference


Personal notes

Three Kinds of Refactoring

  1. As-You-Go
  2. Technical Debt
  3. Rewrites and Overhauls

Technical Debt

We’re going to incur some of it, fact. It’s vitally important that we keep up repayments. People forget that debt repayments incur interest. Schedule in bug-fixing and tech-debt cleanup every sprint. Make and prove the business case for refactoring.

When Not to Refactor

  • If you’re not actually being slowed down by something.
  • If it’s something that can be ignored or avoided.
  • If it’s something that can be captured by a rewrite later on.
  • If a rewrite is the better solution.

Tips

  • defence.css
    • all: initial;
  • .RF-* Classes
    • [class*= 'rf-'] = refactoring done
    • [class]:not([class*= 'rf-']) = work left to do
  • hacking specificity (hacks are alway not nice)
    • Ideally: Refactor until you don’t need the hacks.
    • Realistically: Use one of these hacks to solve the problem.
    • Never: Use !important.
  • shame.css (isolate hacks / self-writing todo list)

Remember…

  • Prevention is than the cure.
  • Technical Debt is fine, just make sure you keep up repayments.
  • Only refactoring once you can see tangible benefits.
  • Avoid long Refactoring Tunnels.
  • Isolate and highlight both hacks and refactored work.