I’m really excited to announce the cleanswifter.com online book club! Participate by reading, or just follow along as I go through the best books in programming, chapter by chapter, week by week. Each Monday, I’ll post a video recap of the latest chapter. The video will include both my personal commentary, as well as live coding examples. For the first book, I’ll be re-reading “Refactoring, Improving the Design of Existing Code” by Martin Fowler. Here’s episode one!
Video Transcription:
Hey, what’s up everybody, I’m Andy, the Clean Swifter. If you haven’t seen it yet, check out my blog at cleanswifter.com where I share tips, tricks, articles, and commentary on how to write cleaner Swift code.
Today I’m really excited to kick something new for cleanswifter.com, videos! Specifically, I’m starting an online book club with you, where each week, I’ll read a chapter in a book, and then post a video demonstrating important topics from the chapter. If you want to read along with me, great, if not, no worries. We can still have a great conversation about the book and the topics regardless.
For the first book, I’m going to be covering “Refactoring, Improving the Design of Existing Code” by Martin Fowler. You can buy it on Amazon, just use the link in the description for this video. I actually read this book years ago in a different world when I was writing server side Java code for a giant web application. I love this book, aside from it being a kind of recipe book for refactorings, it comes with this really cool ribbon that you can use as a bookmark. I have no idea why more books don’t have these ribbons.
I just finished reading Chapter 1, and like most programming books, it doesn’t really teach anything yet, as much as it sets the stage for the rest of the book. One thing I want to get out the way right off the bat is recognition that this book is OLD! It was published in 1999, and now going back to re-read it, certain things in the book are showing their age, not including the technical information. For example, in Chapter 1 Fowler sets up a problem domain where you are building a system for use in a movie rental store. I don’t about you, but I can’t even remember the last time I was in an actual movie rental store. Additionally, at one point, he also mentions “limitations of Java 1.1.” Umm, I think Java is on version 8 now. Regardless, this book is about the patterns and recipes, not the technology used for implementation. Keep that in mind as we go through the book because what’s taught in it, absolutely applies to the Swift code you are writing for your iOS apps.
Another thing that Fowler comes right out and recognizes in chapter 1, is the difficulty in choosing a sample project to use for a refactoring book. Often, refactoring is most important in large, complex systems. Unfortunately, using a project of such magnitude in a book isn’t feasible. You would spend the majority of the time just describing the project itself. On the other end of the spectrum, with simplistic code bases, refactoring seems trivial and pointless. One thing that Fowler asks the reader to keep in mind, and I’m going to ask you to as well, is to imagine the examples we go through as part of a larger and more complicated system.
Throughout chapter one, Fowler goes through a whirlwind tour of several refactorings to improve an initial structure of the video rental system. Since the book will later go through these refactorings in detail, I’m don’t think it’s worth mentioning at this point.
As Fowler sets up the rest of the book, four important points about software design stuck with me: what Fowler calls: “the first step in refactoring,” the need to rename variables and methods as refactoring progresses, how refactoring can actually increase the size of your code base, and finally the need to force yourself not to abort a refactoring because you are prematurely optimizing your code.
Diving into the what Fowler calls “the first step in refactoring.” If you’ve been following me at cleanswifter.com you could probably guess what this is: writing tests. Just like anytime that you are setting out to write or change code, the first thing you need to do is write a test. This follows two categories: tests for the existing code, and writing a test for the expected result of the change. Now when refactoring, you often aren’t changing behavior, so an existing test base can be sufficient, as long as you’re confident that it’s comprehensive. And then, as you move forward with each small change in your refactoring, absolutely run your test suite with each code change to make sure you didn’t break anything, as well as figure out if there’s additional tests you can write for further verification.
The second thing that Fowler mentions in chapter 1 that resonated with me, was the need to rename variables and methods as you move forward with your refactoring. Specifically, he says, “Code that communictes its purpose is very important.” I absolutely agree with this. Please don’t use a variable named “i” – it gives no indication what it does. Additionally, name your tests well. My proposed format for test names captures: what is being tested, what is the expected outcome, and under what conditions. For example, “testViewDidLoad_SetsNameLabel_WhenNameProvided.” And just as good clean code communicates its purpose well, good clean tests do the same. Tests serve as functional documentation.
The third topic Fowler identifies in chapter 1 that I like is how one of his refactorings actually increased the number of lines of code in the project. This is totally valid, and something I’ve seen time and time again. Sometimes you start out with a 1000 line UIViewController, and after a number of refactorings, you get that view controller down to 250 lines of code, but created an additional 1000 new lines in addition to the other 750 lines that also got moved. This is a good thing. The goal isn’t to write less code, it’s to write clean code. I’ve seen single lines of Perl code that do more things than you can imagine, but it’s entirely complicated and difficult to mentally parse.
Finally, the fourth thing that jumps out at me as chapter 1 sets the stage for the rest of the book, is recognition of the urge to prematurely optimize your code. In one example, Fowler refactors a method with a single loop. The new implementation results with two additional while loops. As important as it is to recognize the POTENTIAL performance impact this could have, it’s also just as important to understand that it is only a POTENTIAL performance impact, and that when refactoring, don’t necessarily let a potential performance impact stop you from the refactoring. If anything, move forward with the incremental step towards code cleanliness while following it up with actual performance testing to quanitify its impact on speed.
In closing chapter 1, Fowler recaps that refactoring leads to “better distributed responsibilities and easier to maintain code.” Me, I just call this, “clean code.” One other thing I wanted to call out, a lot of these refactorings are done in light of object oriented design. Keep in mind, these all apply to your Swift iOS code. Just because Swift can support functional language paradigms, doesn’t mean that that’s the only way to write it. These are are all just tools in our toolbox to writing cleaner swift.
Looking ahead to Chapter 2, it’s title is “Principles of Refactoring” and moves towards establishing some common language and rationale for refactoring. I hope you enjoyed this video, the VERY first one from cleanswifter.com. Until next time, happy cleaning.