Refactoring CSS without Losing Your Mind
WEBEXPO | By Harry Roberts
Reference
Personal notes
Three Kinds of Refactoring
- As-You-Go
- Technical Debt
- 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.