"Refactoring" Book Club - Episode 1
Today was a fun experience! We discussed with a few coworkers some highlights from Refactoring. We only covered the first 22 pages as we settled in on the rhythm to keep (way too short). Surprisingly, it sparked a good conversation and we used the whole 30m slot! The role of the facilitator is quite challenging (thank you Jonathan!), which means I'll have to volunteer at some point.
The first topic of discussion came from me and it was about testing. The first thing recommended before you start refactoring is to make sure you have a robust set of tests. This is reasonable, and I admittedly don't have it as a habit. I'm a bit spoiled because we have a strong culture of testing at MongoDB. Most of the time I was able to rely on the existing suite to understand if any of my work introduced a breaking change. I think this approach is both good and bad. It's good because having a solid starting point makes refactoring more predictable. It's bad because you might be too generous in your assumptions about the existing test suite. So my real-life advice is to take a look at the existing test suite (if any) to ensure it's robust and testing the right things. This feels necessary as different folks might feel different about what should be tested. One time we had some legacy code that was testing implementation details, as soon as I made a change and optimized the body of that function, half of the tests failed. Build awareness of the code you intend to refactor by taking a hard look at the existing tests, this will guide you in understanding what the expected behavior is and if the current suite is acceptable. Nothing will stop you from adding or changing existing tests before you start refactoring.
Another interesting point discussed was the granular cycle of making a small change, running the test suite, and finally committing. Admittedly, I go about it a different way. My approach is about making as many changes as I can, as long as they are coherent and don't break tests. If they break tests, I undo them until I have valid changes. It feels more efficient but I can't tell if it's as effective. The tight feedback loop guarantees that you know, for any refactoring step made, which one broke your tests. This strictness might slow you down if you have a large set of tests to go through. On the other hand, you know that every change you make along the way is valid. Unsurprisingly I recommend being judicious about how you group your code changes. Find a balance between efficiency and effectiveness that works for you.
Thoughts
What a great experience so far! I was afraid some of my opinions would not be shared by others but I was happily wrong. We had a nice mix of Engineering Managers, Staff Engineers, Mid/Senior Engineers, so it was a well-rounded crowd. Everyone was able to chime in based on their experience and hopefully learn a thing or two along the way. It is a good exercise to read a book like this with a critical eye and discuss it with peers. It helps develop your intuition further and also gives some insight into how other people look at the approaches presented. Nothing was controversial and we all agreed that, while some refactoring techniques seemed overkill, they still communicated well the mental model Martin Fowler follows when rewriting code. Onto the next chapters now!