refactoring Archives - Page 2 of 2

WWDC 2016 Wish List

WWDC 2016 is less than one week away. I’ve only been to the actual conference once, and that was the 2014 instance. I had such a great time, met people that I continue to stay in contact with despite not having seen them since, and learned so much. That was the WWDC where Swift was unveiled to the world. With such a huge announcement as introducing a new programming language, I think it’s a WWDC that will stand the test of time. In a lot of ways, WWDC is like the one time of year that we developers get a new delivery of gifts from Apple. Gifts that we can use to create new business ventures, deliver new delightful features to our customers, and even gifts that will make our own lives easier- both as developers within Apple’s platform, as well as end users of many apps ourselves. I have no shortage of things that I’d like to see from Apple, both from a developer perspective, as well as an end user perspective. Here’s my WWDC 2016 wish list:

I tried to keep this list in the realm of possibility, and it is ordered by a mild amount of prioritization.

Xcode Swift Support. Yes, you can build Swift apps in Xcode, and I do. And yes, there have been improvements in this area. There are just some fundamental things broken with building Swift apps in Xcode. For example, I hope I never have to see that “Xcode can only refactor C and Objective-C code.” dialog again.

Frankly, I would be embarrassed if I had to put an error message in one of my apps to the tune of, “sorry, you tried to do something legitimate that we just don’t support.” And then to think that this message has been around for going on two years!?!?! Additionally, while less frequent as a year ago, I still get SourceKit crashes in Xcode. That’s when all of a sudden syntax highlighting of your source code stops, and there is no autocompletion. It’s usually paired with an error message. And often, there’s no suggested course to correct whatever you did to crash SourceKit. It’s usually the case that you typed in some non-compilable Swift that rather than getting a nice error message, your IDE stops working. Do you think a third-party IDE would survive with shortcomings like this? I don’t.

Automated Test Support. Reflecting over the past five or so years of WWDC, it’s been amazing to watch the progress Apple has made in supporting automated testing of iOS apps. I remember when first joining the iOS dev community, being astounded by how little Apple made available for automated testing (compared to the Java world that I came from). Fast forward to today, and it’s a fairly comprehensive suite of tools for testing your apps. A couple gaps that I would like filled include:
- Faster test execution – I heard that Visual Studio, the .NET IDE, actually will run your test bed anytime you save a source file in your project. That sounds AMAZING! In order for that to be possible, test execution must be fast. Right now, just to run a suite of a couple hundred XCTest unit tests, it’s about 20 seconds. That needs to be sped up.
- Headless test runners – Right now, running tests (unit or otherwise), require a simulator or device to fire up your app, and run through the tests. This shouldn’t be needed. It would be so nice to run tests without the overhead of the iOS simulator or device.
Continuous Integration Improvements – Xcode Server is a start, but so far from being something that would stand our as a continuous integration solution. I’d love to see Apple take strides to better supporting cloud-based continuous integration. This may even include some amount of supporting xcodebuild on non-OS X based systems (Linux?). Headless test runners would help here too. Right now, without the help of something like Buildasaur, I can’t even get the status of a Xcode Server integration on a pull request. That’s a huge hole in me adopting Xcode Server as the sole solution for continuous integration. Oh ya, and what about even automating some of the process of app deployment, like submission to iTunes Connect? Wouldn’t that be delicious!?
WatchKit Performance. I’ll state right off the bat that I don’t actually have any WatchKit code in production apps at this point. I do have an Apple Watch that I wear everyday. I buy-in to the concept of wearables, especially for health and exercise tracking. The thing is, using the watch is so darn slow and unreliable. Whether I’m asking Siri to start a timer, or using the Strava watch app’s “Start Run” button, either the action simply won’t happen, it will take too long, or some random nasty side effect will happen (like my Strava workout will clobber the corresponding entry in HealthKit). Until WatchKit apps are speedy, and reliable, there’s no chance of success for the Apple Watch in the future. New hardware is not the answer here. It may be part of the solution, but the software stack needs a total revamp.

That’s my WWDC 2016 wish list. If I didn’t say it before, I’ll just reiterate how exciting this time of year is for me, and should be for you too. Even if you need to support older iOS versions, don’t worry, the new features that are announced are still fun to play with, and you’ll eventually get to use them in your production applications. What’s on your WWDC 2016 wish list? If you didn’t see, Apple will be live streaming sessions daily, and posting videos or all sessions throughout the week. Starting next week, I’ll be posting recaps and highlights of all the sessions I find interesting as I consume all this great content from the comfort of my couch.

Happy cleaning.

VIDEO: Bad Smells in Code

Chapter 3 of “Refactoring, Improving the Design of Existing Code” by Martin Fowler, titled “Bad Smells in Code” puts definition on when you know to refactor your code.

Here’s my perspective on the chapter:

Video Transcription:

Hey what’s up everybody, I’m Andy, the Clean Swifter. Welcome to the third video episode from my blog cleanswifter.com, where I share tips, tricks, articles, and commentary on how to write cleaner Swift code. In this video, I’ll be providing some commentary on chapter three of Martin Fowler’s book, “Refactoring, Improving the design of existing code.” The third chapter is titled “Bad smells in code.” You can buy the book through my Amazon affiliate link in the description for this video. In this chapter, Fowler covers a list of specific things, called smells, that should catch your eye and tell you that it’s time to perform a refactoring. I think “Smell” is such an effective word. Often, you won’t know in black and white terms that it’s time to refactor. Instead, your intuition that something isn’t quite right will start to poke at you. Leveraging some semi-formal definition for these “smells” will help you be able to identify them in your code. Throughout the chapter, Fowler actually goes as far to actually suggest specific refactorings in response to various smells. Since we haven’t actually read about what those refactorings are, I’m not going to mention them in any detail yet myself. I was also happy to find that in the back of the book, literally inside on the back cover, is a table reference that lists these specific refactorings that can be performed to correct a bad smell. Here’s a quick tour through some of the code smells that jumped out at me.

The first smell, duplicated code. I bet you’ve seen this one yourself, especially if you’re a liberal copy and paster. It’s name is straight forward. Seeing the same pieces of code sprinkled in more than one place is a clear indication that a refactoring is possible and should happen. One common example might be styling a UILabel. Say some group of UILabels on a page all need a certain look. It’s very easy to copy and paste the common lines of code that set the font, color, and abbreviation style. Unfortunately, when you need to change one attribute of the style, you need to do it in many places, and are likely to miss at least one, thus leaving some labels without the change. Duplicate code is easy to spot. If you see it, you need to address it.

The second smell I wanted to call out is actually three in one: Long methods, long parameter lists, and long classes. Fowler actually lists these are three separate smells, but I’m going to summarize them as one. While there are some slight nuances in how they can be treated, they ultimately represent a piece of code that is trying to do too much. The more lines of code any one “unit” is, whether it’s a method or a class, the harder to understand it will be. Later in the book, we’ll learn refactorings that will help extract common behavior, and break these long pieces of code into separate parts.

The third smells I wanted to mention are shotgun surgery and divergent change. Again, these are granular variation of a common theme: where the need to make one change, results in needing to make many other changes. Divergent change refers to this happening within a single class, where shotgun surgery refers to this happening across many classes. When this smell starts to stink, it’s usually a sign that the single responsibility principle has been violated, or that there is weak encapsulation of behavior. We’ve all gone through this, where we get a request to add a tiny feature, only to find out that there is this cascading amount of changes that are required to implement it.

Feature envy is another common smell. This happens when one class or method, heavily leverages another class, repeatedly, for a wide variety of help in completing a task. See where the name comes from? The class is envious of the features in the other class. This creates an unnecessarily strong coupling between the two classes, which should be avoided when detected. We’ll eventually look at refactorings that help prevent this.

Refused bequest is an interesting smell, one that I’ve come across a bunch with UI code. Refused bequest is when a subclass wants all of the behavior of its parent class, except a certain piece. This happens a lot when subclassing UIKit classes, especially when you start to introduce multiple levels of hierarchy in your own code. Eventually, you’ll create a subclass, where you don’t want the subclass to have all of the behavior of its parent. This is a smell, and rather than code empty methods to override the parental behavior with essentially no ops, you should look to refactor this in a better way.

The last smell Fowler identifies is simply called, comments. And it’s just that, comments in code. I can totally relate to this one. I love how Fowler says that “comments are just deodorant on code smell.” If you find yourself needing to write an extraordinary amount of comments for a piece of code, take that as a sign that there’s probably a refactoring to be done that will help add clarity to the code. That being said, don’t let this stop you from writing comments in your code, just be aware when you all of a sudden write way more than usual for a piece of code.

There were actually a couple more subtle code smells I omitted, and I encourage you to go grab a copy of the book and check them out for yourself.

Looking ahead to chapter 4, it’s title is “building tests.” Fowler puts some clarification around how to build your tests to best support your refactoring. I hope you enjoyed this video from cleanswifter.com. until next time, happy cleaning.

VIDEO: Principles of Refactoring

Chapter 2 of “Refactoring, Improving the Design of Existing Code” by Martin Fowler, titled “Principles of Refactoring,” continues to set the stage for the rest of the “recipe book” of refactorings by explaining some of the basics of refactoring, including:

Why you should refactor your code
When you should refactor your code, and
Problems that could arise when refactoring your code

Here’s my perspective on the chapter:

Video Transcription:

Hey what’s up everybody, I’m Andy, the Clean Swifter. Welcome back to the second video episode from my blog cleanswifter.com, where I share tips, tricks, articles, and commentary on how to write cleaner Swift code. In this video, I’ll be providing some commentary on chapter two of Martin Fowler’s book, “Refactoring, Improving the design of existing code.” The second chapter is titled “Principles of Refactoring.” You can buy the book through my Amazon affiliate link in the description for this video. In this chapter, Fowler covers three important topics, first: why you should refactor your code. Second, when you should refactor your code. And third, potential problems to be aware of when refactoring your code.

Before we jump in, let’s just recap as to the definition of refactoring. Paraphrasing how Fowler puts it at the beginning of this chapter, refactoring is the process of improving code while making no observable changes in behavior. In other words, improving your code, while not changing how it behaves to the end user. You can actually use the word refactor as both a noun and a verb, for example “That refactoring really improved my design” or “let’s go refactor that method to clean it up.”

Now that we’re clear on the definition, let’s dig into the first topic, why you should refactor your code. I know to some people this may be kind of obvious, but let’s talk about it just to be clear. You should refactor your code because it helps you improve its design. By helping improve its design, it will become easier to understand, bugs will be easier to find, and you’ll ultimately be able to add functionality faster. All of these reasons relate to eachother. Messy code will have more bugs. Additionally, because it’s messy, you’ll spend more time trying to find and fix the bugs, and thus spend less time adding end user features. If code is hard to understand, you’ll be slow to enhance it, and when you do, chances are you’ll be adding bugs because you don’t know the true impact of your change. Refactoring aims to solve each of these problems.

Let’s move on to the second important topic, when you should refactor your code. Fowler sums it up simply as “the rule of three.” The first time you do something, you just do it. The second time you do something similuar, you duplicate the first time while wincing. The third time you do something similar, you refactor and remove all the duplication. Think of it as: three strikes and you refactor. I think this is a nice metaphor, but I don’t think I’d live with the first duplication. Any duplication smells to me, I’d probably refactor at that point. When else might you refactor, well any other time that you’re modifying code such as when you’re adding funcitonality, or fixing a bug. Both of those are great times when you can get in and improve the internal structure of your code, while also adding or fixing something in the meantime. Fowler goes on to advocate refactoring during code review. I’m not such a big fan of that, and I think this is another area where the book is showing its age. Today, in a world of github pull requests, code reviews are very common, and I put it on the original author to ensure that the code is in good shape prior creating a pull request for it to be merged into the main code base. In my software collaboration, I’ll usually have worked out the design ahead of time so there aren’t any surprises or really opportunity for further improvement when code review happens.

Finally, the third important topic in the chapter 2 of Fowler’s “Refactoring, Improving the design of existing code” is recognition of some problems that can occur when refactoring. One common thing I run into all the time is a constraint put onto my apps by the backend API. Fowler makes the comparison with a “database” but I’ll move the analogy into something a little more real for apps. As app developers, we need a really solid layer of abstraction between our apps and the backends that you may use, and in my case this is commonly remote web APIs. Otherwise, any refactoring you encounter is going to be constrained by that API and potentially limit what you can do. Similarly, another thing you can run into is if the code you are refactoring is part of a library consumed by others, like a cocoapod, you need to be really careful when performing refactorings that will change that public interface. Doing so will impact any consumers of your API. You need a good migration strategy for them. And another case where you simply shouldn’t refactor, is if the code starts off in a bad or buggy state. If this is your starting point, you should correct any errors first, and then once you have passing tests that cover the error cases, move on to your refactoring.

Those were my big takeaways from chapter two, “principles of refactoring.” Depending on where you are with your refactoring adoption, over time and with practice, it will soon become second nature to constantly be looking for places to improve the structure of your code while ensuring that how it behaves doesn’t change. You’ll even start to integrating refactorings into your thought process while designing your code, before you even write a single line.

Looking ahead to chapter 3, it’s title is “bad smells in code.” Fowler puts some definition around things to look for in code that should be refactored. I hope you enjoyed this video from cleanswifter.com. until next time, happy cleaning.

“Refactoring, Improving the Design of Existing Code” Chapter 1 Highlights

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.

TDD in Xcode – Can’t Refactor Swift Code

Red. Green. Refactor. That’s how I’ve memorized the steps for test driven development. Uncle Bob breaks them into a little more detail if you’re interested in something a little more long form. TDD in Xcode is pretty seamless, until you get to the refactor step. Xcode can’t automatically can’t refactor Swift code.

Refactoring Is Broken For Swift Code

Xcode does not currently support any refactoring of Swift code. If you attempt to use Xcode’s builtin refactoring tools, you see this:

. From my earliest days of writing Swift, this has gotten under my skin. This is friction to my flow. I want my IDE to make it feel like I’m coasting downhill, rather than going up an incline.

Additionally, I also take this as a sign at Swift’s maturity. I’ve since come to see the light, and no longer question Swift’s long term viability, but either way an error message like this should be embarrassing for Apple. And then the fact that it hasn’t changed in almost 2 years…

For more context, if you right click in Swift code to bring up the context menu, any of the options in the Refactor menu show that error message.

Consider An Alternative – AppCode

This weekend I downloaded App Code by JetBrains. I’ve never tried it. Recently it specifically caught my eye that two people I respect, Orta Therox and Jon Reid, evangelize it and use it. JetBrain’s IDEs are renown for the abilities to support test driven development and refactoring. I’m looking forward to giving it a go. I’m in the 30-day trial right now, and I’m committed to learning all it has to offer to make my own impression. So far, I’ve been able to open a non-trivial project and run it in the iOS simulator, no issues. Next, I’m going to do some research about how to best use it, what it offers, and immerse myself in it. I’ll report back here along the way with my findings. I’m just hoping that while Xcode can’t refactor Swift code, I have better luck with AppCode.

Happy cleaning.