Do You Refactor without Tests? It’s Time for Safety
When you refactor, do you have unit tests covering you? …If not, why not? …If so, how do you know?
Source: http://www.ntd.tv/2017/02/14/2016-fails-will-stay-ever/
To me, it seems that the state of refactoring has gotten worse across the industry. Both managers and programmers and managers say the word “refactoring” more than ever. But they almost always mean, “I’m going to change a bunch of stuff. Then at the end, we need to make sure I didn’t break anything.”
But that’s not refactoring. That’s rewriting.
How to Improve Code Comments with Little Refactorings
Does your code have comments? Sometimes they’re helpful. But most of the time…
Don’t litter by Valerie Everett, used under CC BY-SA 2.0
Generate Test Scaffolding & Stay Focused
Quickly generate code for either Swift or Objective-C. Code snippets provided for both Xcode and AppCode.
Code Smells: How Many Do You See in This Method?
It’s time for a quick exercise in code smells!
Striped Skunk (Mephitis mephitis) DSC_0030 by Dan Dzurisin, used under CC BY 2.0
How many code smells do you see below?
The 3 Laws of TDD: Focus on One Thing at a Time
When I was first learning TDD, I’d try to get to the First Step (a failing test) by writing a fully-formed test. But it often took a lot fiddling to get that test to run and fail. Sometimes this was because the production code took several steps to set up. Sometimes it was because the test code wasn’t right.
One of the tricky parts of TDD is that we’re creating two streams of code in parallel: the test code, and the production code. Two things changing at the same time… that’s a hard thing to keep in your head!
My Crazy Plans for the New Year (Book Teaser)
Happy new year! It seems like good time for a Quality Coding retrospective. I also want to share some goals for 2018.
…Did someone say, “Are you writing a book?”
How to Mock Standalone Functions …Without Changing the Call Sites
We’ve looked at ways to mock methods in Swift. But what about standalone functions? Is there a way to mock them as well?
Yes! Not only can we mock Swift standalone functions, but we can do it without changing the call sites.
The last stand by Carl Jones, used under CC BY-NC 2.0
How to Use SwiftLint for Clean, Idiomatic Swift
We get feedback from the compiler. We get feedback from Test Driven Development. But what sources of feedback lie in between?
This is where linters come in. A linter goes beyond “Does the code compile?” A linter answers questions like, “Is the code idiomatic? Is it stylistically clean? Are there any red flags?”
MAGNIFYING GLASS by Rafael Anderson Gonzales Mendoza, used under CC BY-NC-SA 2.0
What Can We Learn from an Incorrect TDD Diagram?
A paper published in 2013 about Test Driven Development included the following diagram. Unfortunately, it gets some things wrong:
Where Will Jon Be in Fall 2017?
Do you enjoy conferences and workshops? Here’s my conference schedule for this fall:
October 7–8: Intro to TDD (non iOS) in San Jose
Last year, I attended Silicon Valley Code Camp for the first time. This year, I’ll be teaching a session: Intro to Test Driven Development.
This won’t be specific to iOS development. Instead, it’ll be platform agnostic, for anyone with a little programming experience.
This year, it’ll be hosted at the PayPal campus in San Jose, California. My session will be Saturday morning at 9:45. You can’t beat the price, which will be little more than a nominal lunch fee.
Send any programmers you know in the area. Also managers! They’ll get a taste of TDD from someone who’s been practicing it since 2001.
Register for SVCC
October 25–26: TDD Workshop in Seattle
My one-day TDD Workshop for iOS Developers has been well-received in Verona, San Jose, Chicago, and Indianapolis. This time, it’s coming to Seattle as part of Swift by Northwest.
The last time I taught the workshop (for a company, not a conference), I kept saying, “Wow, there’s so much we can cover. This could easily be a two-day workshop.” So guess what? This time, you can spend two solid days with me, learning Test Driven Development for iOS!
Register for WorkshopOctober 27–28: Swift by Northwest
The intimate traveling conference CocoaConf has stopped traveling. It’s roosted in Seattle, and taken on a new name. I’m honored to be included in the launch of Swift by Northwest!
My session will be on the SOLID Design Principles. But I want to try something a little different this time:
- No slides. Live scribbling instead.
- Not a “presentation,” but a seminar. There will be discussion.
I think it’ll be a lot of fun. From our shared experiences, we’ll all become better software designers.
Register for Swift by NWWill you be at any of these events? Let me know by leaving a note below!
Single Responsibility Principle: Is It a Fundamental Mistake?
The “Single Responsibility Principle” (SRP) sounds so noble. But I’m afraid it’s misunderstood and misapplied. Ask your teammates: “What is the Single Responsibility Principle?” Go ahead, ask them. Then ask if the SRP is a good thing or a bad thing. I’d bet many of them will say something like this: “In principle, it’s a good idea. But in practice, it’s overkill.”
SOLID Motivational Posters by Derick Bailey, used under CC BY-SA 3.0 US
On Twitter, Chris Eidhof pointed to an example of taking the Single Responsibility Principle too far. Specifically, Chris was unhappy with the argument that Singletons violate the SRP because, besides their main responsibility, they also manage their own life cycle:
This argument against singletons made me cringe (specifically, the SRP point): https://t.co/C9wVVnqHFs
— Chris Eidhof (@chriseidhof) June 29, 2017
This led to a lively discussion. Many reacted against “over-architecture.” No doubt they experienced fragmented code that grew from over-zealous attempts at SRP.
I think that SRP isn’t just over-applied. It’s fundamentally misunderstood, even misquoted. The repeated misquotes perpetuate that misunderstanding.
Let’s see if we can clear things up, and point to a better way.