If you’re like most of my readers, you’re already a successful iOS developer. You’re able to create apps and ship them.
But the older the code gets, the harder it is to maintain. New features aren’t as easy to develop; the code seems to resist change. You’re spending more time fixing bugs than you used to.
Sometimes there’s a call to take existing code and reuse it. This might be in a new target, such as a share extension. Or it might be in a new project altogether. This sounds easy to the product owner, but you find it’s actually quite hard.
Does This Sound Like You? Be Honest:
- Is your codebase becoming easier to manage? Or harder?
- Are there sections of the code you’re afraid to touch?
- Are you free to refactor ruthlessly? Or does the code itself resist attempts to “respond to change,” making it hard to be agile?
If you feel your code is becoming brittle and harder to work with, you’re not alone.
I Know How You Feel
I’ve been in those situations. I was on a team responsible for maintaining a touchy framework used by the rest of a Fortune 100 company. Successful changes became harder and slower. Eventually, the entire team was laid off and the framework was replaced.
At each new job, I’ve been confronted by code that was tangled together.
Never seen anyone refactor like that
Jon introduced Test Driven Development to the team and led by example. I've never seen anyone refactor the large code-base that we had had and contribute to new features at the same time.
But Things Can Be Different
In the midst of chaotic code, I began carving out areas of safety:
- I learned about object-oriented design.
- I started practicing Test Driven Development (TDD) and Refactoring in 2001.
- I’ve been applying TDD to Objective-C since 2005 — first on macOS, then on iOS.
- Now I’m doing TDD in Swift at another Fortune 100 company.
We started from zero TDD
Jon really helped me understand what I should be testing when I didn't know where to start.
My team started from zero TDD and my successes in it have inspired the rest of the team to start. We're now helping each other improve.
All You Need Is a Guide
I would like to be your guide, helping you bring order to your codebase, so that you can sleep better at night.
You don’t have to be overwhelmed. I’m here to help you create iOS code that is maintainable over the long haul. My goal is to equip you with practical approaches that you can put to work to achieve greater success.
All of my iOS changes are now covered by unit tests
When I was just starting with unit testing, I attended a talk from Jon on the different types of unit testing. Jon really helped me understand how all of the pieces come together. He also recommended a set of books which I immediately bought. With the basics covered by Jon's talk and his book recommendations, I now ensure that all of my iOS code has changes that are covered by unit tests. This can be tricky when you don't have access to all the source code you rely on, and a lot of Jon's posts on Quality Coding help with understanding ways in which you can write tests for tricky components unique to our ecosystem.
After a year of using those techniques, I wrote my own testing book based on the principles instilled by Jon. I regularly recommend Quality Coding as a great "get started" resource for people interested in the craft.
If you’ve ever been frustrated by fragile code, or interested in unit testing but afraid it would slow you down — then Quality Coding is especially for you.
Yes, you can tame your code. Let’s do it.