Poorly Designed Systems
Since I love committing to more than I can handle in my spare time, I'm going to try and participate in another book club. This one is led internally at MongoDB by folks who work across App Services and Realm. We're going to read Refactoring by Martin Fowler. The good news is that I started this book a while ago but got distracted along the way as I moved from LA to Austin. I thought this would be a good excuse to pick it up again.
It's not surprising how relevant the act of refactoring is for anyone who writes software. Sometimes it's just lack of experience, sometimes it's the best you can do then, and other times you just have to work with what you got. Either way, refactoring is essential. Building a good habit that is integrated into your team culture will make your codebase maintainable in the long run.
The simple attempt at refactoring your code will already tell you a lot about your design decisions.
A poorly designed system is hard to change
Based on this, we can look at the small picture (a single function) or the big picture (entire components and how they interface with one another). What will be evident, after a few minutes of staring at whichever component you're trying to refactor, is how difficult it's going to be. I'd argue that refactoring per se is never simple. If we think about improving the internal structure without altering any external behavior, there are possibly MANY ways in which this improvement can take place. This is risky business. You're not re-writing for a computer but for humans. Being able to do it in a universally good way is challenging.
Don't let that stop you. I think the first chapter starts pretty well, I appreciate that Martin Fowler explores a practical example. If you paid attention, we mentioned "not altering any external behavior". Thankfully there's a way for us to make sure that doesn't happen: tests! This is something I may not have done consistently in my refactoring efforts. I relied too much on existing ones. Usually, only AFTER my changes and learning more about the logic I was working on, did I have a better idea of what tests I needed to add. I don't think that's necessarily wrong but one approach doesn't exclude the other, making sure I have a strong test suite before I refactor is something I'll do more of moving forward. And you should too!
Thoughts
I couldn't resist the idea of picking up this book again. I liked it back then, and I plan on making the best of it as part of the book club discussions. I could tell you that refactoring is an art, and I partly believe so, but it's about discipline and experience. It's hard if you don't have a picture in mind of what good refactoring looks like, what patterns are simpler to follow, and generally how to make your code more understandable to other humans. I thankfully think very little of my coding abilities, this paid off more often than I thought. The reason is that I am generous at leaving comments explaining the WHY of my choices. This saved more than a few times when I had to pick up code I wrote a year+ before. After a while in the industry, you develop a feeling (sorry for not being particularly precise here, this is just a passing thought), when code you read doesn't seem right. You have put some effort into rationalizing that feeling, recognizing what doesn't feel right and chipping away at it until it does. Refactoring helps you build that mental model, but I'll confirm that once I'm done reading.