Quality Coding
Shares

Category Archives for Code Design

Emoji: Check Mark Button

Refactoring: How Do You Clean a Mess, Safely?

Shares

Refactoring is moving in small steps, with each step verified by unit tests. As I demonstrated last time, these steps are much smaller than most people are used to. Let’s continue the same example to learn some new things about refactoring.

Reading is not as good as doing. I learned from the folks at Big Nerd Ranch that our brains make important connections when we type code. Download my code and walk through the refactoring steps yourself.

Continue reading

Emoji: Magnifying Glass

When You Refactor, Are You Using Small Steps?

Shares

Refactoring remains a much-misunderstood discipline. Even when folks do have unit tests to back their changes, how long does the code stay broken? Let’s return to the idea that refactoring happens in very small steps.

No, even smaller than that.

Continue reading

Emoji: Rescue Worker’s Helmet

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?

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

Emoji: Speech Balloon

How to Improve Code Comments with Little Refactorings

Shares

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

Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.

As Jeff Atwood explains, code tells you how, comments tell you why. A well-placed code comment is a level above the code itself, explaining why something is written the way it is. But! We can express most comments as code, using well-named identifiers. The first edition of  the Refactoring book called this Introduce Explaining Variable. Martin Fowler has since renamed that refactoring to Extract Variable.

Continue reading

Emoji: Nose

How Many Code Smells Can You See in This Short Method?

Shares

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

How many code smells do you see below?

Continue reading

Emoji: Keycap Digit One

Does the Single Responsibility Principle Lead to Bad Architecture?

Shares

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

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?

Shares

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

Inigo Montoya meme: "Refactoring, you keep using that word. I do not think it means what you think it means."

Continue reading

Emoji: See-No-Evil Monkey

Revealing Hidden Objects: Can Domain-Driven Design 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 provides a way.

Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.

Eric Evans’ Domain-Driven Design is a book with many facets. One of my big takeaways is that our code often contains concepts that are hidden. The book’s challenge to me is to recognize implicit concepts, and make them explicit.


I stumbled upon this in the TDD sample app. While applying a principle from the book to the Fetch Characters Marvel Service, I uncovered a useful class.

Continue reading

Icon: JSON logo

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

Shares

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

Emoji: Woman Juggling

Can Improving Your Design Sense Help You TDD?

Shares

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

Emoji: Front-Facing Baby Chick

Look, Mom! My First Spike Solution in Swift

Shares

Swift, here I come!

It’s time to start another version of the MarvelBrowser project. As I did with the Objective-C version, I begin the Swift version with a spike solution. But the first time was to see if I could satisfy Marvel’s authentication requirements. Basically, I needed to get the incantation correct. This time, I know the steps to take, but I will repeat them in Swift.

I have two goals:

  1. Make it work
  2. Make it Swifty

Could you give me feedback on the Swiftiness of my code?

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Continue reading

Emoji: Female Factory Worker

Need Feedback Now? Quickly Hack a Spike Test

Shares

You’re building a new network call to a server. The thing that will actually use this call isn’t ready. But you’re anxious to see the call work in a full round-trip to the actual server. Basically, you want to know: does this part of the code work? How can you get the feedback you need?

Answer: Quickly hack together any way that works.

The agile workflow is to build, validate, and adjust course. Extreme Programming teaches us to use many feedback loops. And fast feedback is the primary benefit of TDD. …But TDD isn’t the only way I’ve gotten feedback on my Marvel Browser:

  • I did a spike solution to learn how to do request authentication for the Marvel Comics API.
  • Having TDD’d that authentication, I wrote an acceptance test to ensure that it works.

This time, I want to combine these two approaches. It’s a hybrid for which I don’t have a name. Maybe a “spike test”?

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Continue reading

3 Easy Steps to Refactoring Tests for Greater Clarity

Shares

I’ve given you 3 Reasons Why It’s Important to Refactor Tests. But what’s actually involved in refactoring tests?

Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.

The definitive book on this topic is xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. It’s a big book, full of patterns and smells. But there are 3 simple steps I take most often.


This is a five-minute screencast where I’m refactoring tests in my iOS TDD sample app using those 3 steps:

Continue reading

Emoji: No Littering

3 Reasons Why It’s Important to Refactor Tests

Shares

You may have seen the 3 steps of “the TDD waltz”: Fail, Pass, Refactor. There are many ways to do it wrong! Two common mistakes are:

  • Skipping the refactoring step
  • Not skipping it, but refactoring only production code

So let me give you 3 reasons why it’s important to refactor tests.

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Continue reading

1 2 3
>