Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
If you have been reading Martin Fowler's canonical article on the test pyramid, you know that there is a mystical layer that hides between those broad unit tests (the base of the pyramid) and the integration tests layer (near the top). This layer is called: component tests.
This article is about the following: What are component tests? Why should you care, and how to implement them properly?
Kent Beck was asking about “Feature Flags” on Twitter recently and their life cycle. Former colleague, Pete Hodgson linked back to an article he’d written to for Martin Fowler a couple of years ago, and added context.
I don’t think this article fits in that Tweet series, so it’s a standalone blog entry — much of which I’ve shared before.
Software systems are prone to the build up of cruft: deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt.
Imagine I have a confusing module structure in my code base. I need to add a new feature. If the module structure was clear, then it would take me four days to add the feature, but with this cruft, it takes me six days. The two day difference is the interest on the debt.
Over the past week or so, I’ve been reading Refactoring by Martin Fowler and it’s all about how to make sweeping changes to a large codebase in a way that doesn’t cause everything to break. I bring this up because there’s a lot of really good notes in this book that have challenged my recent approach to auditing and refactoring a ton of CSS. A lot of the advice is small, kinda obvious stuff, but I realized that I’ve recently been lazy when it comes to how many of those small, obvious things I brush off on projects like this.
Martin writes:
…if I can’t immediately see and fix the problem, I’ll revert to my last good commit and redo what I just did with smaller steps. That works because I commit so frequently and because small steps are the key to moving quickly, particularly when working with difficult code.
So: commit frequently and only do one thing in that commit. Further, constantly test those changes as you code.
The other thing I’ve started to be more aware of — thanks to this book — is that commit messages are precious things because they help other folks understand the meaning of changed work. We’ve all seen seemingly simple commit messages, like “refactored typography” that turn out to be thousands of lines long and we roll our eyes. That’s just asking for bugs to be introduced and visual regressions to happen. Smaller commits should prevent that sort of thing from ever happening. A good string of commit messages should sort of feel like you’re pairing with someone, as if you’re walking them through the changes step-by-step.
Although I’m getting better at this, I find this method of working extraordinarily difficult because it feels slower than sweeping changes and hoping for the best. In his book, Martin encourages us to subside that feeling. When we’re refactoring large portions of our codebase, he argues, we should always be slow and steady, patient and disciplined.
The post The Slow and Steady Refactor appeared first on CSS-Tricks.