talk-therapeutic-refactoring
https://www.youtube.com/watch?v=J4dlF0kcThQ
Takeaways
tests make you smarter by giving you an exobrain ^tests-make-you-smarter-by-giving-you-an-exobrain
you need tests to be able to refactor effectively
if you optimize for developer happiness by making your test suite fast, you get loosely coupled code that adheres to the single responsibility principle
sub-second tests are a huge enabler of flow, and flow is amazing! (so true. mdpg's tests run in less than a second, and I love working on it!)
High Level
- creates characterization tests
- extracts methods
- eliminates code junk
The problem
- untested code
- in production
- on cron job
- very large method
- does things at two levels of abstraction
- comment that lies! (in my opinion, all comments are comments that are just waiting to lie!)
One problem is that it does things at two levels of abstraction ^two-levels-of-abstraction
Characterization tests
Characterization tests, AKA quarantining code by surrounding it with regression tests.
In her testing she was able to determine that the square brackets weren't being replaced. Then she left that in as documentation of how the software actually behaved.
Using mocks and stubs to reverse-engineer the interface
She starts with the happy path, but doesn't end there... once they are all passing, she goes line-by-line to try to figure out what each line does and add tests that test the edge cases. Nailing down the happy path, first, is critically important, though, as it then gives her the confidence to be willing to inspect the code line-by-line.
You can see that she deliberately tries to think of problem input, and combs over the code for issues, thinking "what if this is nil?", "what if it's long", "what if it's short?"
"I think it's really important to have really solid characterization tests when you're trying to clean up a mess" - KO on RR episode
This is the confidence-gaining part of the talk. By the end of the "first middle" she feels relatively confident in her understanding of the code
Refactoring
"when you were refactoring that, building that file name and you pointed out that all of the, like a lot of the lines were, you know, file name and then the chevron to, you know, stick something else on the end, to append something... you immediately pointed out the things that were not the same as the rest of the method." Chuck RR
Quotes
From the talk
"I would specifically put something into its own class so I could load just that class and nothing else. The feedback loop you get when you have sub-second test suites for the thing that you're working on is unbelievable. It's a huge enabler for flow." ^sub-second-tests-enable-flow
"I was constantly asking myself, can this be a separate class? What is the unrelated sub-problem here?"
"Test suites should be curated, maintained, fed, watered, coddled"
I take this to mean "red, green, refactor, refactor tests", or as Uncle Bob said on the GRSIOGR podcast the same thing, but refactor the tests first.
from the Ruby Rogues episode
"one of the things that I didn't do in the talk but I did in the real code is that I defined some shared examples that just define that API, the accepted messages and then I run the map against the stub and against the original object."
"Refactoring makes you smarter. Refactoring basically gives you an exobrain. So you offload a bunch of those little details that under normal circumstances go into working memory into your tests. Once you start refactoring you start reclaiming your brain." ^exobrain
Later reflection
She talks about how she's taken to doing random acts of refactoring. It sounds like it's a link not tracked