Best Practices in Software Development

Introducing Reduxion-iOS: Easy-To-Implement Clean Architecture for iOS Apps

TL;DR:
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:

• “MVC”
  … 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.

A Realization

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 days’ worth of unnecessary effort to modify, and even then was incomplete — I realized that existing 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 such 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.

Enjoy!

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