Best Practices in Software Development
Introducing Reduxion-iOS: Easy-to-implement Clean Architecture for iOS apps
Inspired by work from others, I’ve created an easier-to-use implementation for best-practice Clean Architecture and Unidirectional Data Flow in iOS apps. It’s open-sourced on GitHub.
“The usual, please … some Spaghetti Code, with a side of Technical Debt”
Over the years, I’ve often been dissatisfied with code I’ve seen on various client projects.
And these aren’t low-budget endeavors — they include efforts for Fortune 500 companies, and have even carried seven-figure price tags. Some have been better than others, of course, though too many have suffered from:
… Massive View Controllers
- Low Cohesion
… lack of a single responsibility (SRP) per object
- Brittle / Tight Coupling
… poor separation of concerns (SoC) amongst classes and architectural layers
- Technical Debt — in large and expanding amounts
… and excessive difficulty in adapting the code to changing requirements (thus impeding the business from being truly Agile)
- Unnecessary hurdles to practicing automated testing (TDD/BDD)
… and bloated / non-performant test suites that take hours to run
- Poor readability, and non-intuitive or “clever” naming
… creating inefficiency for others in understanding & working with the code
- and more …
And none of these scale well, over size or time.
Eventually, I had an “Aha!” moment:
After needing to make one trivial change on a project — which should have taken a few hours — but ultimately required a couple of days’ worth of effort … I realized that code had, in fact, been created by smart, experienced developers, with years of practice on the platform.
Wait — what?
It’s surprisingly common:
- Best architectural and coding practices aren’t articulated or enforced on a team, or are an afterthought. Thus, even experienced devs may not have had optimal patterns to emulate, and so end up repeating the same anti-patterns for years.
- The primary focus has been in meeting one deadline after another, on one project after another, so they haven’t had bandwidth to learn those practices on their own.
- Many devs aren’t around to see the cumulative result of their choices over time, and how that affects those who inherit and have to maintain the code they’ve written.
- Not all best-practice patterns are easy to implement and follow.
And the eventual “solution” for that existing code …?
Crisis Meets Opportunity
After researching a number of available architectural implementations … I was inspired, but not quite satisfied with anything I’d found.
So I created my own:
Reduxion-iOS leverages the best features I’d seen elsewhere (and adds in some items from my own wish list):
- Loosely-coupled layers
… for View / Business Logic / Data / Services
- Composable business logic
… in single-responsibility units
- Good separation of concerns
… facilitating automated testing (TDD/BDD) that’s performant and not brittle
- Ability to switch the entire application between real and mock services
… with one line of code
[This largely decouples front-end from back-end development, if needed.]
- Ability to easily persist & recall the entire state of the application
… without any database framework at all
- Ability to easily add time travel (rewind/fast-forward)
… between different states of the application
The approach has worked out well enough that I wanted to share it with others: Here’s the project on GitHub.
(And please let me know what you think.)
P.S. “Reduxion” is pronounced “reduction” … hopefully of spaghetti code and tech debt. :)
Stock images © Can Stock Photo. All rights reserved.