Category Archives for iOS Architecture & Design

Do You Refactor without Tests? It’s Time for Safety

Shares

When you refactor, do you have unit tests covering you? …If not, why not? …If so, how do you know?

People trying to weigh down pitchfork as it tilts dangerously

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.

Continue reading

How to Improve Code Comments with Little Refactorings

Does your code have comments? Sometimes they’re helpful. But most of the time…

Continue reading

Code Smells: How Many Do You See in This Method?

It’s time for a quick exercise in code smells!

How many code smells do you see below?

Continue reading

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.”

Single Responsibility Principle poster: monster Swiss Army knife

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 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.

Continue reading

Refactoring Demo: Is It More than Just Changing Stuff?

Refactoring. It’s a word I hear quite a bit. Usually, in the context of conversations with management, it means, “Rewriting that thing. Hopefully without introducing bugs.” Often, among developers, it means, “One of the options in the Refactoring menu in my IDE.”

Continue reading

Revealing Hidden Objects: Can DDD Improve Your Code?

Shares

Code that’s easier to understand, maintain, and extend — that’s the promise of Object-Oriented Programming. But the reality for many iOS developers is that our objects are bloated. They know too much, and do too much. What if our code has hidden objects, waiting to be found?

Each hidden object could provide a new abstraction, a new tool. They could make the code more manageable. Is there a way to discover these hidden objects? Domain Driven Design (DDD) provides a way.

Continue reading

How to Safely Parse JSON into Swift Immutable Models, All with TDD

How can we unit test JSON parsing, handling every possible error? Can we generate immutable models? And for Swift, how can we keep our Response Models free of optionals?

Of course, there are many JSON parsing libraries out there. Plug one in, define all fields as non-optional, and you’re good to go! …Until your app crashes, because something was different in the actual JSON data.

Unlikely? “The backend team would never do that to us”? I’ve had a released app crash because the backend folks changed one field from a string to an integer. I’ve seen app development and QA forced to pause because a commit assumed all fields were non-optional. (It crashed on the missing field, because Swift.)

So let’s look at a pattern that will help us

  • Handle required types
  • Avoid optionals
  • Deliver immutable models

Even if you never plan to do your own parsing, we’ll learn things along the way about design and testing.

Continue reading

Your TDD Will Improve as Your Design Sense Improves

When you’re new to Test-Driven Development, there’s a strong tendency to continue writing code the way you used to. Then you step back and ask, “But how can you unit test this? TDD is so impractical!”

Almost always, my answer is: “Then don’t write it like that.”

Apple recently published a blog post, Working with JSON in Swift. I was looking for tips on Swift JSON parsing, and found the beginning of the article quite helpful. But it took a bad turn at the end…

Continue reading

Mental Block? This Is One Weird Trick for Improving Your Code — Really

You face a problem with your code. Maybe something is bugging you about the design approach. Or maybe you’re just plain stuck. What can you do to break through a mental block?

"Free Your Mind" graffiti

free your mind by justanotherhuman, used under CC BY-NC 2.0 / Cropped from original

During one job interview, I remember asking how the candidate approached problem solving. That candidate’s answer has stuck with me over the years:

Continue reading

What Would MacGyver Do? Quickly Hack a Spike Test!

Shares

I’ve been TDDing the “fetch characters” network request to the Marvel Comics API. But I’m anxious to see it work in a full round-trip to the actual Marvel server. Basically, I don’t want to go long without end-to-end feedback. How can I get the feedback I need to validate the current code?

Answer: Quickly hack together any way that works.

Continue reading

>