Many developers have told me the VIP cycle in Clean Swift has helped them a LOT. It’s a complete mindset shift in terms of how you build iOS apps. And they wanted more. The VIP cycle and its unidirectional nature are awesome. But what about the workers and custom views? They want to know how I would design classes and functions outside of the VIP cycle.
Maybe you found out about Clean Swift and read some of my articles, because you are an iOS developer who wants to take that next step. You want to learn how to write maintainable and testable code. But your existing app is built with MVC or MVVM, and you’re dealing with massive view controllers or massive view models. At this point, it’s just not feasible to switch the app to a new architecture. It’s already built, just slightly broken. Or, it is just a pain in the butt to work with on a daily basis. You want to keep your existing architecture, but also want to do things right. There is hope. You can still practice good software design principles to your classes and functions regardless of your app’s architecture.
You may have read and learned about design patterns, but are having troubles knowing when, where, and how to apply them to their own projects. Design patterns are iterated and proven from real, working, large scale software. They are valuable knowledge over many years. Understanding and applying them is an essential skill to acquire in your development career.
But understanding != applying. Reading and learning about design patterns alone doesn’t make writing well designed software any easier. Everything makes sense when you’re reading. But applying these patterns to real projects is totally different. It requires you to be extremely conscious about every line of code you write. At the same time, you are trying to focus on solving the problem on hand. Your brain is doing two things at the same time. We can think and drive a car at the same time easily. But deep thinking and problem solving are not meant to be multitasked. Our brains just aren’t wired to do that. You can’t be implementing a feature while trying to make sure your code adhere to all the software design principles.
Real Software —> Designed Patterns WORKS
But:
Designed Patterns —> Real Software DOESN’T WORK
In other words, extracting good design patterns from real working software works. But trying to force feed design patterns into software doesn’t work.
In this book, I turn that traditional approach upside down. I choose to take an architecture-agnostic and design pattern-agnostic approach to explain good software design. I won’t be talking about the design patterns explicitly. Instead, through working with a simple function, I’ll demonstrate how you can write good software by explaining with plain old English that you can understand. You’ll find that it’s just common sense. You’ll not need to do the mental translation from design patterns to good working code. You’ll just write good working code.
And there’s one more thing. Software does not stay the same. Software evolves. Requirements change. In the book, we’ll introduce a change in requirement and evaluate the before and after version of the code to see which is easier to maintain. Maintainability doesn’t just apply to app code. You’ll also learn how to write maintainable unit tests, and know to fully cover your app.
Start writing better functions today:
Buy Function Keys now for just $29
