It would be hard to overstate the importance of Redux to the early explosion in popularity of React. The two quickly became nigh inseparable—like peas and carrots. Redux’s emphasis on immutability and the dead simple action-reducer pattern meshed seamlessly with React’s functional reactive programming and one-way data flow. To such an extent, I might even argue, that it became something of an obstacle to a proper conceptualization of React, the component tree, and front end application architecture in general. The two combined to craft a seductive pitch that it was most appropriate to view your app as one giant component function, fed from the top by one giant piece of immutable application state.

This simply isn’t true in practice, of course, and structuring your components to optimize re-renders against store changes will quickly result in many quasi-independent component trees, firmly shattering the mirage of a 1-to-1 relationship between the top-level state and UI rendering. Edge cases like ghost children—where a child component may re-render from a store update before the parent component, when it is in fact destined to be removed entirely after the parent has re-rendered—further muddle the conceptual symmetry between Redux and React.

Still, the abstraction was so beautiful that the combination of React+Redux was omnipresent until relatively recently, and of course it still has many adherents.

In retrospect, however, Redux kind of greased its own wheels a bit too much. The written-in-concrete ‘best practice’ of having a single store per app—which itself was instantiated from a static set of reducers known at build time—pretty much forced that symmetry on somewhat dubious motivations. After all, there’s no reason in principle why a single React app can’t be a combination of two completely orthogonal sub-applications, each with its own independent store. There are architectural patterns which would encourage exactly this, “micro-frontend” being just one.

An early confusion that this ‘best practice’ induced was the conflation of “one store” with a “single source of truth.” Early React/Redux developers will recall running battles over the correct way to integrate Redux with react-router. The resolution of that concern was, in essence, to disabuse ourselves of the falsehood that single source of truth means having a single library interface, and that as long as the router was the source of truth for routing and Redux was the source of truth for general application state, there was no single compelling reason to integrate or synchronize them. Yet another crack in the illusion of a 1-to-1 symmetry between the Redux store and UI.

More recently, other state management libraries have largely abandoned the notion that one giant store is necessary or proper, and “single source of truth” is returning to its traditionally understood meaning of avoiding duplicative logic or state. This has its own dangers, and the decentralization of external state management these libraries enable could itself work against the SSOT principle. Still, the principle of orthogonal concerns tells us that we should be able to add a piece of shared state to our app without necessarily having to impact on any existing code, and libraries like Valtio or Zustand allow exactly that.

At the end of the day, the only really compelling Redux pillar that remains standing on rock solid foundations is the supremancy of the immutability of data structures. This is what allows us to optimize our component renders, and ensures consistency across all the consumers of a given piece of state. It goes without saying that this is a guarantee that new state management libraries continue to rely on, and even make more robust—for instance via use of proxy facades for update tracking. (Redux reducers, on the other hand, are famously prone to bugs where an object or array is mutated in place, by accident.)

I’m in the middle of reading Reframe Your Brain, by Scott Adams, and it has inspired me to write up some of my own strategies for self-improvement and coping with life’s inefficiencies. Without further ado, here are five of my own “reframes” that have served me well, and could even be life-changing in the right circumstances.

Avoid temptations by slightly delaying them

How often do you have a craving you know you’ll immediately regret? Maybe something small, like Friday night Dominoes—but you’re down to your last $20 and you’ll eat it too quickly and feel sick, anyway. Maybe something bigger, like an expensive gaming PC you’ll barely touch after the first few days. It could even just be the next sugary snack from the kitchen cupboard.

Something that has worked very well for me is—firstly—not to judge or dwell on the craving. Instead, I set a time in my head when I am allowed to have whatever it is I’m craving. For the snack that might be the next half or quarter hour. Pizza delivery: an hour or so in the future. Major purchases might get put off until pay day.

I give myself permission without judgement because there’s a very good chance that the craving will have passed by the appointed time. An additional rule I might apply is that I have to start over with a new time if I miss the appointed time and the craving comes back. Often, I’ll not even notice and the craving will simply pass out of mind.

I’m not anxious, I’m excited

I forget where I learned this trick, except that it ultimately came from an actual psychology study. The key insight is that, physiologically, anxiety and excitement are the exact same thing. The study participants were tasked with an anxiety-inducing activity, such as public speaking. Before taking the stage, they clapped their hands and announced to themselves: “I am excited.” This simple mental shift had profound effects on their performances.

I have found this trick to be useful even for generalized anxiety. If I’m working on a project and start to feel anxious, instead of allowing it to negatively affect my work, I pause, clap, and tell myself that what I’m actually feeling is excitement. It can help to have some concrete reasons already in mind for why you should be excited, if needed.

I’ve even used this with some success to get over my anxiety of flying. For me, it’s mostly the take-off (and its lead-up) that causes anxiety, and I’m fine once we’re in the air. So, I tell myself that I’m not anxious—I’m excited to get to the good part of the flight. It’s always good enough to get me into the seat, at least.

The 5-year regret horizon

This one is very simple. Anything that happened more than five years ago simply did not happen. Missed opportunities, professional setbacks, friendship-ending arguments: if it was more than five years ago, it has now rolled off your emotional credit report.

The moment something pops into your head from college and you begin to ruminate, visualize a large STOP sign, remind yourself that it happened over 5 years ago, and refocus on something more recent. Odds are, whatever that is won’t get its hooks as deeply into you, and your mind will be free to move onto more productive thoughts.

The only goal is to start

One of my most counter-productive instincts ever has been to set benchmarks at the outset of trying to form a new habit. It feels good to have a schedule in mind (when getting started running/jogging, for instance) of so-many minutes or so-many miles a day. That schedule itself feels amazingly like progress, but it is the exact opposite!

Take a wild guess how many days in the first month I felt up to running for a solid 45 minutes before I had even laced up my sneakers. Funny enough, it did not take very long at all until you couldn’t have dragged me off the treadmill once I got warmed up. The days that I actually got on the treadmill and then tapped out at 10 minutes were few and far between. There was zero correlation between the amount of motivation I felt beforehand and how much energy I had once I got started.

Again: all the schedule and my benchmarks did was make it less likely that I would even get on the treadmill at all. Once I got on the treadmill, the benchmarks had zero to do with keeping me on it. The schedule was 100% a drag on my new fitness habit.

What actually did help was literally anything that made it more likely that I would just get off my ass and start. Clean workout clothes set out with my running shoes. A full water bottle that was easy to drink from when mid-stride, waiting by my keys. A go-to playlist queued up on my phone.

Maximize for just getting started, minimize anything that gets in the way of getting started, and worry about the 45th minute after the 44th minute, and not a second before.

Effective fantasizing for better sleep

Like many people, I used to have an awful time getting to sleep at night. Many nights, my brain just would not shut down. I won’t elaborate further: this might be one of the few truly universal human experiences.

I stumbled upon the strategy that has worked for me quite by accident. Wish fulfilment fantasies, by themselves, weren’t enough to pierce the bubble of anxiety and rumination to calm my brain down. What did the trick was painstakingly fleshing out the details. The more pedestrian the details, the better. I call these exercises “sleep teasers.”

An early sleep teaser of mine was to imagine waking up in the sickbay of the starship Voyager, lost in the Delta Quadrant. This wasn’t just a Mary Sue author-insertion fanfic. Instead, I worked my way through what my first days on the ship might realistically entail: being assigned quarters, having to program the replicators with my favorite junk foods, figuring out how to become a useful and valuable new crew member with skills four centuries out-of-date. Absolutely zero space battles or warp core breaches.

The fantastical-but-mundane nature of sleep teasers seems to be important. Another one I’ve used often is to imagine that I’ve proved (or disproved) a famous open mathematical problem. I’m utterly unqualified ever to do such a thing, but I’ve read books on the subject and have a general mathematical education, so it becomes more a game of mathematical fiction: coming up with a means of proof that would sound plausible enough to your average hard science fiction enthusiast. Sometimes these confabulations have prompted questions or personal insights into the real-life mathematics involved, but that’s just a bonus, if it happens.

Playing the lottery can help, if you have some detail-prone but low-key dream that jackpot money alone could enable. What exactly would it take to set up an animal sanctuary? Or to move back to your home town and open a book store on the square? What’s important is a balance between the pleasantly unrealistic fantasy and the mental problem-solving to work through. On the Voyager, I still got to meet and interact with the characters. Having proved the Riemann Hypothesis, I got to bask in the fame and collect my just rewards.

Whichever sleep teaser I settle on any given night, I tend to quickly settle into a pattern, retracing many of the details of the same mental story. This familiarity and routine, I’ve found, leads inexorably to sleep.

Bolting static type systems onto dynamic languages is all the rage, these days. TypeScript, of course, has long since taken the “what if JavaScript but not JavaScript?” crown. Even Ruby—the lucky-duckiest of loosey-goosey dynamic languages—is bending in that direction. The motivations are understandable: these languages began as scripting languages, but now they’ve become the primary languages for a vast amount of application development at scale. The anything-goes ethos of loosely-typed dynamic languages that hit the perfect cost/benefit balance for dropping a bit of “dynamic HTML” into a website twenty-five years ago starts to lose its luster after the first 100,000 lines of code or so.

Wherefore art thou static typing?

The benefits for development teams are straightforward, and compelling enough, on their own terms: statically-typed code is self-documenting (a huge boon for code completion and documentation tools) and static type checking eliminates a swath of low-hanging runtime bug fruit, along with a perceived need for a lot of low-value tests to guard against those failure modes. The strictures of the typing system can enforce or encourage more thoughtful top-down architecture and code design. Psychologically, embracing typing is very helpful for breaking out of an unhelpfully defensive mindset when writing code: what if someone passes a completely unexpected value to this function? Well, they just can’t, if that would entail a different type. Their problem.

The downsides are equally straightforward.

Typed languages are manifestly less expressive than untyped languages; what you lose in expressiveness, you gain in what you can prove about your code and its behavior. Clawing back some of that expressiveness makes the typing more complicated, both in theory and in practice. This is the problem we run into when we fall back into the duck typing mindset and “just want to do something simple” like map a function over an array of objects, plucking a property from each: now all of those things (“array”, “object”, “property”, “map”, “function”) fall within the type checker’s jurisdiction, and the type checker only likes what it can trivially prove to be correct, given what we’ve told it or what it can infer. Enter interfaces, protocols, traits, generics, sum types, type guards, and/or whatever other type system constructs a given language features for polymorphism.

It’s not a slam-dunk psychologically, either. Static typing is a big mental shift. Not as big as, say, going from object-oriented programming to functional programming, but big. It’s natural to fight against the type system’s strictures, to struggle to regain the flexibility, expressiveness, and apparent simplicity of the underlying dynamic language. For every programmer who immediately embraces the guarantee that a well-typed function prevents arbitrary types from being passed as arguments, there’s another programmer who valiantly persists in writing verbose, overloaded functions to “safely” allow arbitrary types to be passed as arguments. This can actually result in more brittle code than the untyped equivalent, and instill a false sense of progress, to boot.

The biggest downside—since it can insidiously and silently undermine every benefit while exacerbating every cost—is that optional type systems, by their very nature, leak like a sieve. A key principle of type checking is that the entire code base is one unified type universe. If you can’t, in principle, trace a value and its type through every possible caller and code path, verifying that the types are compatible at each junction, then it’s not static type checking—that’s just type annotations. That’s why the simple map function turns out not to be so simple to type correctly: our function’s implementation may be isolated and encapsulated, but the types inside that function are not. Enter the any type, a way to drop back down to dynamic typing on an ad-hoc basis.

An any type is the type system equivalent of the principle of explosion: it allows the type checker to prove anything, and thus prove nothing. Its use in one file might not automatically infect your entire code base, but if widespread it absolutely will entail the static typing reducing to little more than hit-or-miss code completion. Untyped contagion is not an unmanageable risk, but I wonder how many teams do so successfully, or even take it seriously in the first place? There are probably a lot of legacy internal JS libraries out there with .d.ts files chock full of any. Caveat typtor, one might say, but considering the resources and energy being sunk into adopting these systems, one might also hope for the actual end value proposition to be a bit less contingent.

Amusingly, if you went back to 2010 and told a conference of web developers that the consensus view in 2021 was basically that JavaScript should have just been Java from the get-go, you’d be laughed off the stage. The situation we find ourselves in is highly path dependent. The way we know that JavaScript, if it were to be re-invented today, would be nowhere near as loosey-goosey with types is because people are constantly re-inventing JavaScript today, almost always with some amount of type-safety as a core motivation. To be clear, I do see, over yonder, a Big Static Type Rock Candy Mountain coming into view. I’m just not convinced that the current muddle is a worthwhile step forward to that promised land.

I love static typing. It’s the best.

I do a lot of my “recreational” programming in Haskell, which is both intimidatingly strictly-typed, on one hand, and also a hotbed of experimentation for type system expressiveness, on the other. I heartily recommend Haskell to programmers of any experience or skill level who want an in-your-face demonstration both of the power of type systems and their shortcomings, along with all the ways those can be addressed via opt-in extensions (each, of course, with their own shortcomings.) What it boils down to is that you can’t extend a type system so far that it becomes as expressive as the untyped (any) lambda calculus without losing all of the benefits of the type system. There is always a balance that must be struck between what you want to express in your code and its types, and what the type checker can practicably prove. This entails some deep insights into the nature of programming, languages, and types.

Something else that programming with Haskell can highlight is how responsibility for correctness extends well beyond even the most expressive type system. Extremely robust and battle-tested standard libraries, such as Control.Monad, almost always come with caveats: an interface (called a “type class” in Haskell) implementation (“instance”) is valid if its functions satisfy not only the required type signatures, but also some other conditions outlined, informally, in the documentation. Often this means that the results of combining the functions in various ways should have some invariant property, such as associativity or distributivity. It is left up to the programmer to ensure that an implementation conforms. Rejoice, for this is a version of the full-employment theorem for programmers.

There’s also an applicable cultural lesson, in the existence of a function called unsafePerformIO. The short story there is: “Don’t use unsafePerformIO”. The longer story is: “No, seriously. Don’t use unsafePerformIO.” It’s the any of the Haskell world: the ultimate escape hatch from a miserable situation. It’s the only way to run an IO action without binding it to main (which itself is the only way for app code to safely run an IO action) because it is the only Haskell function that can actually perform side effects before returning. If you peruse the Haskell standard library, you will, in actual fact, see unsafePerformIO used a fair bit. This is because the usual “safe” use of IO—binding to main at the top-most level—is itself implemented atop unsafePerformIO. In other words, unsafePerformIO isn’t intrinsically unsafe, but the onus is on the programmer—the library programmer who writes the unsafePerformIO call, not the library user—to “convert” it to a safe use. This is, to put it mildly, a very high bar.

Haskell programmers are incredibly ornery about unsafePerformIO and maybe three people in the world are allowed to use it without a mandatory psychiatric evaluation. any isn’t nearly as unsafe as unsafePerformIO, and in fact may be just the magic ticket needed to get code that should work dammit over the hump, and there’s the rub. You can say it’s not “best practice” all you want, but so long as the easiest, most surefire way to get serviceable code working and deployed is to turn off type checking and revert to dynamic typing, then you can take it to the bank that that is exactly what’s going to happen, a lot.

Of course, it’s absolutely possible to write entire libraries without ever opting out of type checking. That’s literally every library ever written in a real statically-typed language. I wouldn’t be surprised, at all, if the big TypeScript projects don’t have a single any anywhere in their source, or if they do it’s surrounded by FIXME flags and links to outstanding TypeScript issues, and carefully isolated from the rest of the well-typed code. I also wouldn’t be surprised, at all, if there are also plenty of small-to-medium-sized projects that have any sprinkled maybe not everywhere, but here and there… only as required to quickly fix a critical bug, or in dubious contributions pushed upstream from a major corporate user, perhaps. Corporate SWE orgs jumping on the TypeScript wagon en masse because a Senior Vice President read an article in BusinessWeek? Forget about it. For every perfectly any-free open source library there are, assuredly, scores if not hundreds of apps, deployed to production, that are absolutely drowning in a sea of any.

And, yet…

Static type systems can enable amazing, nigh-miraculous things. Stream fusion, for example, is a technique for automatically rewriting otherwise 100% natural and conventional list processing code (maps, filters, folds, zips, and so forth) to eliminate, in most cases, the need to allocate intermediate lists. The trivial example is a function that maps over a list of numbers and doubles their values, and a second function that maps over a list of numbers and increments their values by 1. In the naïve implementation, composing those two functions would allocate a list of doubled numbers, and then a final list of incremented numbers. What stream fusion can do, in so many words, is dissolve the individual loops and recompose the functions on the individual list elements, instead. A huge factor in being able to do such things correctly is static typing: being able to know, purely from the types of the functions, that compositions of those functions can be safely rearranged and optimized, transparently.

That’s just for starters. With a language like Haskell, you can prohibit imports of the IO type or unsafePerformIO, and have a high degree of confidence that the untrusted code you’re about to run can’t have much of an effect on the external world—barring a zero day exploit—beyond putting itself into an infinite loop, or eating up memory unnecessarily. If that sounds unimpressive, then you probably haven’t tried to do anything remotely equivalent in vanilla JavaScript. Team up with the most talented JavaScript programmer you know, and try to block him/her from, say, getting access to fetch, heuristically. Even if you can eventually swing it, you’ll never have the confidence that comes from all access to the external world being promoted to a single type.

Type systems are all about what the type checker can prove, and parlaying that proof into real, concrete benefits. Merely implying or not excluding the possibility of type correctness is, frankly, worse than no type checking at all, since it can seriously lead a team astray, induce significant over-confidence, encourage dubious development practices bordering on cargo-culting, and be very expensive in time, money, and personnel. By all means, if you’re writing a well-isolated, robustly-engineered library from scratch, and have the wherewithal to rule out falling back to dynamic typing here-and-there, when the going gets tough, then don’t let me stop you. If you have a pre-existing and sprawling code and dependency base of mission-critical vanilla JavaScript, and a large team of engineers to match… why on Earth would you want to tee up this particular moon-shot? Best case scenario, you would be making the perfect the enemy of the good… and, in my experience, at the end of the day the perfect never actually turns out to be much of a challenge to the good enough, when it comes to developing and releasing software.

You might say that I’m the one making the perfect the enemy of the good. What’s wrong with opt-in type checking, for those who want to use it, or for the code that’s easiest to adapt? Even a marginal benefit is a benefit, no? Sometimes it’s a benefit, sometimes though it’s just a wrecking ball to your stack, overall code quality, and engineering processes. Static type checking that doesn’t actually give you high confidence—and a low chance of high confidence is actually just all-around low confidence—in its correctness isn’t a benefit of any sort… it’s just code bureaucracy.

1. React is not an architecture

As modern libraries go, React has remarkably minimal API surface area. This is greatly to its credit: it handles a small set of closely-related concerns and avoids the weird mixture of egoism and insecurity of do-everything frameworks. It’s a toolbox starter set, instead of a custom-built multi-tool. This can be confusing for developers used to the guardrails of frameworks that come with neat buckets for all their code—controllers here, data entities there—and an all-encompassing metaphor for how those pieces fit together.

I once worked with an engineer who believed, rather perversely, that Ruby being so thoroughly and dynamically object-oriented meant that the lessons of the last 40 years of object-oriented development no longer applied. You didn’t need the principle of interface segregation when you could just use metaprogramming to change the interfaces on the fly; and global function spaghetti was no longer global function spaghetti if the functions were written, laboriously, as classes with a single call method. His code was some of the worst I’ve ever dealt with, not because he was stupid, but he overfocused on maximizing what he could do, and let himself be convinced that, in this brave new world, none of the old wisdom—mostly concerned with should instead of could—was relevant.

“Everything is a component” is to React as “everything is an object” is to Ruby: trivially and misleadingly true. The error is in seeing this as an end, when it’s actually a beginning: closer to a language extension than an easy-bake app toolkit. Like many libraries or frameworks, React’s quick out-of-the-box successes seem to bely the emergent complexity of real-world projects at scale. Simple apps or proofs-of-concepts can often be built out without much thought for any additional structure, creating the impression that no additional structure is required. (That’s usually the case, generically: if libraries didn’t automatically reduce complexity and make certain tasks easier on the local scale, at least, then they wouldn’t see any use at all.) The avoidable conceit is that because React’s simple and clean design requires only one kind of sprocket, then one kind of sprocket is all that you or your application should have.

It’s incumbent on the developer to anticipate the need for additional structure, and to resist the illusory simplicity of “a component is a component is a component.” A Ruby application that consists of just subclasses of Object without any architectural patterns will devolve into code spaghetti quickly, and so will an application that uses React without drawing any distinctions between different flavors of components. That entails, for instance, drawing a meaningful distinction between something like a generic Button component, on one hand, and a top-level Signup screen, on the other. It extends to seeing built-in helpers like the useContext and useReducer hooks from the same perspective: as low-level tools that could be splattered like semicolons all across your codebase, but probably shouldn’t be, if they’re not contributing to good software architecture and code design.

Ultimately, the simplicity of React itself is not a get-out-of-engineering-free card. On the contrary, the onus is on developers and teams to implement generally applicable patterns and principles that will serve us just as well in every future project, and which can be quickly grokked, in the abstract, by new team members.

2. React is a library for creating user interfaces

Zoom out too far and this becomes a bit tautological: in one sense, your entire front-end app can be seen as just a user interface for your back-end API. On its own terms, however, React is handling a familiar set of concerns for the front-end: rendering/compositing graphics primitives, and event-driven user input. In other words: it’s a view layer. Logic bound up too tightly in a view layer can be hard to reuse and is notoriously difficult to test, and the interface itself can be subject to dramatic changes, so it’s important to constrain the scope of your components’ responsibilities in much the same way as you would a custom UIView in a native iOS application.

No, that doesn’t mean building out parallel hierarchies of “view controllers” or such, but it does mean that care should be taken to ensure that data manipulation, domain and business logic, and so on, are appropriately separated and abstracted from the user interface code. Common lower-level patterns like Redux go a long way here, but there aren’t any intrinsic guards against just falling into the habit of treating your application and your user interface state as one-and-the-same, and without a modicum of care they can end up just as tightly coupled as inlined logic would be.

Furthermore, the idea isn’t that application logic should be separated from the user interface because you might change the entire underlying system (i.e., swap out React for Ember) on a whim, but because the two concerns themselves should be easy to change on their own terms. This is exactly the same as maintaining a common, generic API backend that can support scripting, a web interface, and multiple native apps. They’re not separated so that they can be completely replaced on a whim, they’re separated so that they can evolve—in ways small or large—with minimal knock-on effects for other systems.

A simple rule of thumb is that if code isn’t managing presentation or handling events, then it probably shouldn’t be baked into a React component. That said: what happens at runtime is potentially a different story. The crucial point is that your code design should prioritize separation of concerns, but ultimately every program is a final, hard coupling of its substructures and dependencies; the fact that a library like react-redux, for example, ties everything back together into a meta-structure of React components isn’t the issue, the issue is when you sacrifice the ability to separate your application code from React, at any level, even conceptually, you’re increasing the carrying cost, and sacrificing flexibility, extensibility, and reliability, for no good reason.

3. Don’t wage a battle against HTML and CSS

Fact is: the vast majority of apps that use React will never run on any platform other than HTML and CSS in a current web browser. If we exclude React Native apps, that can just be taken to be 100%. Ignoring the finer points of HTML and CSS, or trying to abstract them away entirely, serves little purpose, but can lead to a lot of extra work and maintenance costs.

Even developers who weren’t around for the early days of the Web when <table> was used primarily for page layout can take the kneejerk aversion to tables way too far, to the point of re-implementing <table> as a raft of components, consisting of a nest of <div>s or <span>s, and a raft of finicky, potentially buggy custom CSS. It’s really quite simple: if your data or interface is tabular, then you can just use a <table>, that’s what it’s there for. If you want to lay things out in a grid that aren’t actually related to each other two-dimensionally (i.e., the rows and columns aren’t semantically meaningful and orthogonal) then, duh, don’t use a <table> for that. Not only does <table> handle most of your markup and positioning for you, it’s also more readable, and the built-in semantics are used by browsers and screen readers to enhance accessibility, automatically, without finnicky ARIA configuration.

It ought to go without saying, but any UI designers on the dev team should also know HTML and CSS and be familiar with the default behavior and known limitations, so that they’re not pushing UI embellishments that are easy to whip up in Sketch in lieu of proposals that would work just as well but with a much simpler implementation. Trying to abstract the developers themselves—so that the designers’ Sketch files can be treated, purely on their own terms, as an abstract, gold-standard hand-off from one team to another—is far worse, and leads to an explosion of complexity, byzantine UI hacks, a general breakdown in code quality, and immense developer frustration.

Key to succesful application development, with or without React, is knowing your materials, and having a sense of what is high-value-for-effort innovation and what is low-value development hell (custom scroll bars, custom drop shadows, pretty much anything else that can be summarized as “a custom-built version of some browser-provided functionality so that it can be styled slightly more flexibly.”) Finding the right balance between abstractionism and reductionism can sometimes be tricky, but that, much more than knowing the syntax of any given programming language, is what developers do.

4. SVG icons don’t need to be React components

On the flip side, the fact that React works by taking XML-style syntax and using it to render and update a DOM tree can be irrelevant implementation detail and a costly red herring. If you’re using it for something other than rendering your app’s user interface, then there’s probably a better, more efficient tool, ranging from a simple template string on up to a purpose-specific library like D3. Purity as a development priority is meaningless, here: there aren’t any prizes for unnecessarily baroque solutions that only serve to maintain the comfort blanket of a universal API. (Full disclosure: I’m totally guilty of having written a kludgy port because I didn’t really understand why an interface that made sense in one paradigm didn’t make any sense in the other. More on that another time.)

A particularly common form of React abuse is to look at a set of SVG icons, to see that SVGs are XML documents, to note that React supports rendering JSX to SVG, and then, finally, to convert all static SVGs to React components. Please do not do this: the fact that an image file format’s underlying implementation is XML does not mean you want to be rendering those files as React components. Browsers are perfectly capable of loading and rendering graphics files all by themselves, in several different ways, whether that’s a PNG or an SVG. The underlying XML format is an utterly irrelevant implementation detail, and using the React hammer on that particular nail doesn’t do anything but worsen performance and limit expressive power.

That doesn’t mean there aren’t any uses for generating an SVG document in a component, but if you wouldn’t replace icons/email.png with an EmailIcon component that drew the icon procedurally, with a series of curves and stroke operations, to a <canvas>, then why would you want to do the equivalent to icons/email.svg? Leave your SVG files as SVG files. Even if you think you have a reason not to, look for alternatives.

For example, it’d be much simpler to have 4 static arrow SVGs than to have one ArrowIcon component that takes a direction property and applies a rotation transform to the path. Likewise, for outline or filled versions: the absolute last thing you want to be doing is tweaking stroke thickness via a component’s props. That way lies madness. Leave the SVG-tweaking responsibilities to Sketch, lest the first change request come in a week asking if a certain icon can have one part be stroked but another part be filled, and then the next one asking if another icon can have two stroke widths, ad infinitum. That doesn’t sound so bad? Well, now we have separate stroke and fill versions of icons, but only for half of them—React can handle that, right? Don’t fall into this trap.

Maybe handling SVG icons as generic image assets seems less flexible in terms of what you can do with any given specific icon, but that’s a good thing, because, in the general case, you don’t want that flexibility, and it is ultimately illusory: in 99.9% of cases, there’s nothing you can do with a per-icon React component and stylesheet that can’t be handled in the icon SVG files themselves, as a graphic design concern, using a real vector graphics editor. Furthermore, the same set of icons ought to be usable universally, in other applications, email templates, or promotional materials. Do yourself a favor, and make less work for yourself by leaving SVG files as SVG files.

A perennially popular topic in software engineering circles is “monolithic” architectures and how to fix them. Architecture being a bit of a misnomer, since often the problem is the lack of any architecture. The way the story goes is that you have some 10-or-so-year-old web application. Over the years your faithful steed has grown to include so much interrelated functionality that the gears of progress are grinding to a halt with each additional line of code. That single application handles your onboarding, billing, content, messaging system, gamification, third-party integrations, and many additional systems, which are coupled in often insidiously mysterious ways.

There is more than one strategy for dealing with this sort of situation. The most popular is probably despair. Another is microservices, which involves splitting all that functionality into separate, logical applications.

This can be a huge improvement. It can also be an excuse to get bogged down by a ton of technology-creep and research expeditions. What it often isn’t is a change in architecture. It is hard to pull off the microservices gambit successfully without decoupling and cleaning up a ton of code, this is true. Many of the benefits that accrue, however, tend to be from simple refactoring and physically enforced separation of concerns. Often times, the individual services end up looking much the same as the original app, just cut down to size and cleaned up a bit. To be clear: this isn’t a bad thing. Nor is it a universal experience. What it also isn’t, necessarily, is a different architecture.

Perhaps I’m splitting hairs, here. If someone wants to talk about reducing horizontal integration as an architectural concern, that’s perfectly fine—the end result is still better software. Where I wish there were greater attention given is the architectural problems of vertically integrated code, and how to resolve them. I actually have to give a tip of the hat to Rails, here, because this actually was recognized as a problem, fairly early on. “Skinny controllers, fat models” is a good example of a “best practice” that evolved out of an effort to reduce vertical coupling in the application stack. Of course, those “fat models” are a problem all their own.

What do I mean by vertical coupling? Well, I work mostly with APIs on the server-side of things, often with the Grape framework. It is incredibly common to see—and not just in a project using Grape—the following concerns combined into a single class: routing/transport, conditional authorization, business logic, database access, serialization, and data shaping. There are probably others. These are all things your app needs, but by collapsing them to a single point the complexity can explode enormously.

Imagine a set of finite state machines—each one can be delightfully simple and together they can be combined in useful and efficient ways. If, however, you decide to take three state machines that are always used in conjunction and just smoosh them together into a single state machine, you’re almost guaranteed to create a huge, unmaintainable mess with a massive increase in the number of states and transitions. That’s what happens when you combine all those concerns together in one place: the number of states that code represents jumps enormously, making it harder to reason about, harder to change, harder to test, and harder to have confidence in.

What we want to do, ideally, is separate at least some of those concerns and move them behind architectural boundaries.

For example, Grape is great at describing the shape of your external HTTP API—your routes, verbs, and parameters. Forget for a second that some users shouldn’t be able to access every route. There should be, in principle, a sort of API platonic ideal that just describes every possible way HTTP can be used to interact with your app. You should also be able to describe that form without hardcoding in your ORM classes or business logic. Of course, a bunch of HTTP endpoints by themselves is pretty useless. The thing is, the fact that you access your app via HTTP isn’t really an integral aspect of your app. It might be an unchanging aspect, but what your app does is what your app does whether it’s accessed via HTTP, websocket-based messaging, a command line, or some hypothetical future protocol.

It’s right there in the name: Application Programming Interface. An interface is an abstraction. An interface is a mechanism for separating concerns while ensuring they can continue to be composed and used together. There are actually two interfaces at play, here. There’s the super obvious one where you’re defining endpoints that a browser or app can hit. There’s also the more pure interface of your application business logic and its underlying domain. Squashing the two together is a mistake, because it robs you of the key advantage of the second kind of interface: the ability to vary its implementation.

Why would you want two implementations of your application? You don’t. The thing to remember is that we’re talking about two implementations of an interface, not two implementations of an application—the larger part of your application should itself be encapsulated appropriately. The actual concrete implementations of its public interface(s) should be only a small part of your total application code.

OK, why would we want two implementations of the interface, then? Well, one reason could be to provide one implementation that is limited in functionality, for unauthenticated or unprivileged users, and a second implementation that implements the entire interface. Now, access control can depend only on which implementation gets injected into the external, web-facing interface, in a single location, rather than sprinkling potentially brittle and conflicting authorization guards throughout the HTTP API. Think of how much easier it would be to reason about and test your access control when you take HTTP routing and requests out of the picture entirely.

This is obviously a light sketch of one possibility, but hopefully the advantages are clear. Sometime soon I’ll have a second post, about the practicalities of following this approach with Grape, along with concrete examples.

Perhaps the central issue in software design/architecture is the appropriate handling and constraint of complexity, both up-front and as the software grows. To that end, there are many frameworks, in whatever your chosen language, which have reducing or eliminating complexity at their core purpose. They’ll call it “being opinionated” or “convention over configuration” or some other catchphrase, but they all boil down to, essentially, the notion that taking work and responsibilities away from the developer is the same thing as taking away complexity. This is true, up to a point.

If it weren’t true, no one would ever use any of those frameworks. (Except for, perhaps, Java developers.) The problem is that complexity is a bit like trying to grip a balloon in your fist—squeeze parts of it with your fingers, and other parts will get pushed out wherever there is room. Over the long-term, complexity tends to out, and the harder you try to squeeze it down the more likely it is to explode. By letting the framework lull you into complacency, and ignoring the complexity at the beginning, you’re risking a descent into a lifetime of add-on, callback, and middleware hell to eek out even small improvements in functionality.

This isn’t to say that it is all doom-and-gloom. A good framework can help you get off the ground running. A good developer can use his or her preferred framework judiciously, and can keep themselves from falling into an inescapable black hole of coupling app code ever-more tightly to the framework. A framework is like a giant ox, in that they’re both tools that can really help you out in the short-term, and also really hurt you for the long term, if you don’t approach them with a healthy respect for their dangers as well as their advantages.

People who know my opinions on the matter are often surprised when I tell them that I use ActiveRecord in certain projects. The difference between how I use it and how many large Rails projects use it is that my “models” are a few lines long and consist almost entirely of relationships. I use it as an ORM, and only as an ORM. Any actual business logic is elsewhere, and ActiveRecord is simply a convenient DB querying and data access tool. Because those classes are only used to save and load data—and not, say, to handle the logic of moving money between accounts, or calculating reports, or syncing to Redis, or any number of things that can be crammed into an AR subclass—they’re purely an architectural boundary. On the app side, they’re wrapped by a bridge class with an interface derived from the app and business logic, not from ActiveRecord. As a result, there are zero unit tests that involve AR in any way, the app code can be comprehended and maintained without caring about AR, and systems design decisions like which database storage system is most efficient for different pieces of data can be made almost completely independently of the software engineering.

The tough part, conceptually, is seeing these as good things. Something I’ve heard frequently is “well, we use Rails, so why shouldn’t we use a Rails feature if it’s there?” The “use it because it’s there” impulse is a strong one. This is where the framework making things really easy at the beginning starts to come back to bite: a framework is almost always going to have an easiest-possible solution for something. StackOverflow will have 20 users fighting to be the first to tell you what that solution is, and to claim that their solution is “best practices.” Part of being a software engineer, or a programmer if you prefer, and not a code monkey is not automatically forfeiting those decisions, and instead taking a step back and looking at the effect on your app as a whole. If that simple, “best practices” solution involves turning a 900 line file into a 901 line file, then it’s worth considering what brought things to that point, why that one file does so much, what happens the next time any of that needs to change, and just how confident you are that it actually works as intended.

Engineers love design patterns. They make our jobs easier, because they provide us with a lot of time-tested, proven ways of solving common problems. We also love design principles, which help guide good code design. Confusing the two is a common, and unfortunate, mistake that can lead an engineer down a deep well of poor code design that can be hard to escape. We all know a principle when we see one (Single Responsibility Principle, etc), but what, exactly, is a design principle?

A design principle is a top-down, goal-directed, descriptive heuristic.

It’s top-down, because design is top-down: high level concepts and systems are recursively decomposed into smaller systems and finally into classes. That doesn’t mean starting with a complete spec, but it does mean that, whatever your methodology, the end result needs to make sense from that perspective. If your end result has no high-level design then the process has failed.

It’s goal-directed, because it’s in service of external goals and not a goal in-and-of itself. Those goals are many but include: ease of testing, long-term maintainability, reusability, and velocity. A design principle that makes any one of those things worse is less than useless.

It’s descriptive, because it describes a likely ideal outcome without necessarily prescribing the means to achieve it. The difference is between giving someone enough information to reliably identify a cow, and that person trying to reconstruct a cow from that description without seeing one in advance.

It’s a heuristic, because it’s a rule of thumb, not a law. Heuristics help us get into and stay in the ballpark, by cleaving off unlikely or obviously unpalatable alternatives. Once there, though, they don’t help you identify the right answer. Occam’s razor, for instance, is a heuristic that is often abused. It says that the simplest explanation should be preferred to others. The point isn’t that any given simple explanation is necessarily more correct than a more complex one, it’s that simple explanations are preferable as a practical matter to more complex ones (and note they need not be mutually exclusive,) and, more importantly, as a basis of inquiry they’re likely to prove more fruitful.

So when applying a design principle, keep these things in mind:

• Are you applying it as part of an actual design process? Are you going to end up with a series of well-structured, coherent, and reasonable systems and classes, ordered into appropriate levels of abstraction? At any given level and for any given system, can you hold the entire thing in your head and comprehend it reasonably well?
• Are you making things easier for yourself in the long term, or just making a bigger mess on a large scale for the sake of applying a principle on the immediate, small scale?
• Are you just applying it by rote, as if it were an algorithm? Are you judging your use of the principle from the perspective of finished, high-quality software, or by whether some cookie-cutter pattern has been universally applied everywhere possible?
• Have you considered whether it even applies, or whether it applies in the same way as it has in other situations?

The Monty Hall problem is a classic example of a provable, simple truth that runs entirely counter to our expectations. When it was widely distributed in Parade Magazine in 1990, thousands of readers—many very well educated, including scientists—wrote in to vigorously disagree with the proferred conclusion. Yet, computer simulations have (trivially) proven the extremely intuitive solution to be incorrect.

The problem is simple, and is based on the game show “Let’s Make a Deal.” A game show host presents you with three doors. Behind two of the doors is a goat. Behind the third door is a new car. You’re invited to select one of the three doors. After you pick your door, the host opens one of the other two doors to reveal a goat. He then gives you the option of switching to the door that you did not pick and that he did not open. Should you switch?

The answer is yes—your odds of winning the car are doubled if you switch. The intuitive answer is “it doesn’t matter”—there are two doors, one of which definitely has a car behind it, so if you were to flip a coin and pick one you’d have a 50% chance of picking the right door. That answer is provably incorrect. So, what’s going on here?

Let’s step back and take another look at how this could go. You’re back in front of the doors, which have been reset. This time, after picking your door (let’s say you pick door C) the host offers to let you either stay with the door you picked, or get both of the other doors (A & B). If the car is behind door A or door B, then you win it. Should you switch?

Of course you should. It’s plainly evident that two doors give you twice as many chances to get the car. With one door, you only have a 33% chance of having picked the car. There’s a 66% chance the car is behind one of the other two doors. Now, remember again that there is only 1 car, and 2 goats. That means that at least one of the two doors definitely has a goat behind it. The question to consider is: are the odds different if the goat is behind door A rather than door B? You know for an absolute ironclad fact that one of them is a goat, so does it matter which door has a goat?

Let’s say you switch. At this point, your choice is locked in. The host reminds you that behind one of the two doors there is definitely a goat, and asks what you think your odds of winning are. You tell him that you’re twice as likely to win as not win, since you have 2 chances to get the car. Then the host says “What if I were to tell you that behind door A is a goat, what are the odds now?”

There remains, of course, a 66% likelihood of winning the car.

There was always going to be a goat, behind either door A or door B (or both, of course.) And the host was always going to tell which one had the goat, regardless of whether it was door A or door B. You have received absolutely zero new information that would affect your odds of winning the car.

This scenario is completely identical to the original formulation, where the option to switch is given after the goat is revealed. There is no new information, you always knew there was a goat, and you knew the host was going to show you one. The key to all of this, and what makes it counter to our intuitions, is that the door opened to reveal the goat wasn’t chosen randomly. The host was never going to open your door, even if it held a goat. So, even though there are now two unopened doors to choose between, the odds aren’t equal because the two sets of doors were treated differently.

If a complete stranger were to come across the set and see the three doors with one already open to reveal a goat then it would be a coin flip for that stranger—because they don’t know which door you initially picked. That extra information is what tips the odds in your favor if you end up switching.

I’m working on an experimental graphics app that delegates a lot of functionality (including user-scriptability) to (mostly) pure functional code, written in Haskell. To be clear, the point here isn’t to “write a Mac app in Haskell.” Instead, my Haskell code consists of certain domain-specific operations on data structures. Transformed data is returned to the main app, to be interpreted as appropriate.

There are two main problems to solve: (1) integrating the Haskell part of the app in the first place and (2) exchanging structured data between Swift and Haskell. This post is Part 1, and I’ll discuss marshaling data across the boundary in a later post. The first step turns out to be pretty simple, in contrast to the impression given by an article on the official Haskell wiki on the subject. This post covers the process for an Application target. Framework targets are a bit different, and will be covered in Part 2.

The Haskell Code

Haskell integration with other languages is based on the Foreign Function Interface (FFI.) The FFI handles translating/calling the external function (or vice-versa.) All we have to do is tell it a little bit about how the function gets called, and what the types are. We’ll start with a very simple function:

module Triple where

triple :: Int -> Int
triple x = 3 * x

I went with triple to avoid any confusion with Double. In order to export this function to be called elsewhere, we have to first include the ForeignFunctionInterface language extension at the top of the file:

{-# LANGUAGE ForeignFunctionInterface #-}

The last thing we need to do is actually export the function. Note that the typing situation can be a little weird, and FFI provides the Foreign.C.Types module with C-specific types. In this case, however, the normal Int type works just fine.

foreign export ccall triple :: Int -> Int

ccall specifies the calling convention, e.g., how to find the function and its arguments in memory. In this and most cases ccall suffices, and tells the compiler to use the C calling conventions. Finally, we simply repeat the function signature. Note that in many cases it will not be this simple to translate a Haskell signature into the C-compatible version. That’ll be covered in more detail in Part 3.

Compiling The Haskell Code

GHC has a gazillion flags… the man page is truly frightening. Luckily we need only to use a handful. The command to compile our simple Haskell file looks like this:

ghc --make -dynamic -shared -lHSrts -lffi -O -o triple.so triple.hs

There’s a lot going on here:

• --make combines all the modules of your code and the dependencies in one step
• -dynamic specifies using dynamic Haskell libraries.
• -shared generates a shared library
• -lHSrts links in the Haskell (HS) rts library
• -lffi links in the FFI library
• -O (that’s a capital ‘o’) enables default optimization
• -o triple.so specifies our output filename
• triple.hs is our input file

Add Files To The XCode Project

The compiler will output four files. The only two we’re interested in are triple.so and triple_stub.h. Add those to your project. Ideally you would just add references to the files, so that modifying and recompiling the Haskell source won’t necessitate any copying or re-adding of files later.

Configuring The Header Files

In your bridging header file, add #import "triple_stub.h". If you don’t have a bridging header, you can just create a new .h file and name it projectname-Bridging-Header.h.

triple_stub.h includes HsFFI.h, which is part of the core GHC libraries. We have to tell XCode where to find the header file, via the project inspector. Under the “Build Settings” tab, find the “Header Search Paths” setting and add the location of the GHC includes directory. On my system that directory is:

/Library/Frameworks/GHC.framework/Versions/Current/usr/lib/ghc-7.10.2/include

but your mileage may vary.

Final XCode Build Settings

triple.so should have been added automatically to “Linked Frameworks and Libraries,” at the bottom of the “General” tab for the app target. If not, add it now.

This isn’t enough to actually make the library available, though, so we have to tell XCode to copy it via the “Build Phases” tab. Click the “+” at the top and add a “New Copy Files Phase.” Set the “Destination” dropdown to “Frameworks.” Now, drag triple.so into the file list for the new build phase.

Setup Complete!

Now that we have our project set up, we can call our function from our Swift code just like any other C function that is automatically bridged for us. The only caveat is before we call a Haskell function we have to call hs_init to setup… I’m not entirely sure what it sets up. There is a corresponding ‘hs_exit’ function to call when we’re all done with Haskell.

func applicationDidFinishLaunching(aNotification: NSNotification) {
  hs_init(nil, nil)
  NSLog("\(triple(4))") // => 12
  hs_exit()
}

Sending and receiving more complex data will require a bit more work, and I’ll cover that in a separate post.

Tests shouldn’t have to be changed or updated all that often. If they are, then they’re getting in the way of what tests are supposed to help us achieve: high velocity, effortless refactoring, code maintenance, etc. High test churn is an indication that something is wrong with either the testing methodology or the code design. The proximate causes are legion: lots of stubbing/mocking, large numbers of dependencies, spaghetti classes, testing glue code, high level (integration) tests masquerading as low level (unit) tests, and so on. This is a separate issue from keeping tests DRY. If your helper modules or shared contexts are churning, then that’s likely as much a smell as if you have to constantly rewrite the tests themselves.

There are three main kinds of problems, in my experience:

Testing The Wrong Thing

It’s really easy to test things you shouldn’t, especially if library glue/boilerplate code makes up a significant fraction of your app. There’s sometimes an insistence on exhaustively testing “our code,” even if our code doesn’t actually do anything. Or there might be pressure, internal or external, to write tests just to say you wrote tests. Often this will take the form of testing rote configuration of some framework class, which is a combination of code duplication and testing third-party code. Not only are you probably “testing” something that is liable to change, but you’re quite possibly coupling your test to your implementation, at best, and the implementation of a third party library, at worst.

A very rough rule of thumb is not to write a test if you didn’t actually write a function or method yourself. In those situations where you do feel the need to write a test, then it should be functional: varying inputs and asserting on results, not interrogating and asserting against internal state. A good example might be validations built into an ORM class: testing those validations should be functional, i.e. the validate method should be called with actual valid or invalid data—simply using introspection to check that “this class has a uniqueness validation registered on it” is pointless.

Testing Too Much

If you fall into the mindset that good testing is to throw a veil over the code and rigorously test against any conceivable bug via every single access point, then it’ll be easy to ramp up the quantity of tests you write to an absurd level. This can result in a lot of test churn if the things you’re overtesting end up changing—and they probably will. For example, you might write a bunch of tests that verify logic for a method that simply forwards its arguments elsewhere. Test logic present in the class, method, or function. Don’t test delegated logic.

For instance, if you have a method that does some sort of computation, and another method that composes that method:

def calculate_tax(product, state); end;
def tax_for_order(order); end;

Then tests for tax_for_order shouldn’t be testing that individual taxes were calculated properly. The tests for calculate_tax handle that. A good rule of thumb is that if you find yourself testing more than one thing for a given method/function, or testing the same thing across multiple test subjects, then you’re either testing logic that is elsewhere or logic that should be elsewhere. How applicable the rule is will vary based on how vital the thing you are testing is, whether it’s public vs. private, whether it’s part of an interface that client code might use, etc. In general, though, well-written code will have simple, single-issue tests. In this example, tax_for_order might initially look like this:

def tax_for_order(order)
  if @states_we_tax.include?(order.state); end
end

Now you’re testing at least two things: (1) Whether we even charge tax on this order, based on the state and (2) What the tax for the order should be. Code that is more cleanly tested might look like:

def order_subject_to_tax?(order); end;

def tax_for_order(order)
  if order_subject_to_tax?(order); end
end

(An even worse initial version might be something more like @states_where_we_have_warehouses.include?(order.state).)

Testing Poorly Designed Code

There’s nothing wrong with mocking, stubbing, test doubles, etc. However, too much mocking, or stubbing in low-level unit tests, can oftentimes be a code smell. Having to mock or stub a lot is a strong indication that a class is too tightly coupled, either to its dependencies or because the class combines a lot of responsibilities. If you have to stub the class you’re testing itself, then something has gone horribly wrong. If you’re stubbing or mocking some internal method, then you’ve hit on something that should be in another class in the most direct and obvious way possible.

Too much mocking/stubbing can be caused by a class having too many dependencies. Having many dependencies is, furthermore, an indication that your class is doing too much. Often this’ll be paired with large methods that tie everything together. One of the chief benefits of testing is its ability to highlight larger-scale design problems: if it sucks to test something, it’s probably poorly designed. Being at a loss for how to test something, or even just really not looking forward to it, is a strong indication that you should be refactoring, not papering over the problem with painful, complex tests.

Conclusion

None of these problems are peculiar to any particular testing methodology. However, if you’re encountering them while ostensibly practicing TDD then you should step back and reconsider how much you’re actually letting the tests drive the code. Actually writing tests first is a key part of TDD, of course, but putting the tests first is, in my opinion, both more important and often overlooked entirely.

I’m working on a brand-spanking-new iPhone app, for the first time in a while, and I’m trying to take a fundamentals-first, good-design approach to development, rather than simply regurgitate the patterns I’ve used/seen in the past. Here are three “new” approaches I’m taking this time around. Each of these patterns are broadly applicable regardless of your language or platform of choice, but with iOS development, and XCode, they can take a form that, at first, might look odd to someone used to a particular style.

Clean Up View Controllers With Composition

Ever popped open a class and seen that it conforms to 10 protocols, with 20-30 mostly unrelated methods just piled on top of one another? This is a mess: it makes the class harder to read and debug, it makes individual lines of logic harder to test and refactor, it can mean an explosion of code or subclasses you don’t actually need, and it precludes sane code reuse.

By applying the single responsibility principle—and the principle of composition-over-inheritance—we can mitigate all of those problems, moving code out into individual classes for each protocol/responsibility. You’ll win gains pretty quickly when you realize, for instance, that a lot of your NSFetchedResultsController-based UITableViewDataSource code is nearly identical, and a single class can suffice for multiple view controllers.

That goes for view code, too: If you’re poking around in the view layer it’s probably a good idea to do it in a UIView subclass. The name of the game isn’t to minimize the number of classes in your project, and separating code by function appropriately is the basis of good code design. For that matter, the name of the game isn’t merely “code reuse” either—whether or not you’ll ever take two classes and use them independently isn’t the mark of whether they should just be smooshed into one giant class.

Cut Your Managed Objects Down to Size

What’s the responsibility of your NSManagedObject subclasses? To coordinate the persistance of its attributes and relationships. That’s it. Taking that data and doing various useful things with it is not part of that responsibility. Not only do all those methods for interpreting and combining the attributes in various ways not belong in that specific class, but by being there they are manifestly more difficult to test and refactor as needed. If you’re looking at a bit of code to—I don’t know—collect and format the names and expiration dates of someone’s magazine subscriptions, why should that code be dragging all of core data behind it?

At a minimum, most of those second-order functions can be split out into a decorator class or struct. A decorator is a wrapper that depends simply on being able to read the attributes of its target object, and can then do the interesting things with reading and displaying that data—without involving core data at all. How do we eliminate core data entirely? By using a protocol to reflect the properties of the NSManagedObject subclass. Testing any complex code in your decorator is now a cinch—just create a test double conforming to that protocol with the input data you need.

This is a super simple example of a decorator I use to encapsulate a Law of Demeter violation. This illustrates the form, but the usefulness pays increasing dividends as the code gets more complex. Note, also, that you needn’t have a single decorator for a given model… different situations and domains might call for differentiated or completely orthogonal decorators. In that way, decorators also provide a way to segregate interfaces appropriately.

protocol ExerciseAttributes {
  var weightType: NSNumber? { get }
  var movement: Movement? { get }
}
extension Exercise: ExerciseAttributes {}

struct ExerciseDecorator {
  private let exercise: ExerciseAttributes?

  init(_ exercise: ExerciseAttributes?) {
    self.exercise = exercise
  }

  var name: String? {
    return exercise?.movement?.name
  }
}

Storyboards Can Help Manage Composition

I used to have a knee-jerk reaction to storyboards. They felt like magic and as if all they did was take nice, explicit, readable code and hide it behind a somewhat byzantine UI. Then I realized what they really do: they decouple our classes from each other. The storyboard is a lot like a container. It lets us write generic, lightweight classes and combine them together in complex ways without having to hardcode all those relationships, because there’s another part of our app directing traffic for us.

After you’ve moved all your protocol and ancillary methods from your view controllers, you’ll probably end up instead with a bunch of code to initialize and configure the various objects with which the view controller is now coordinating. This is an improvement for sure, but you still end up with classes that mostly exist just to strongly couple themselves to other classes. That glue code is also so much clutter, at best. At worst it has no business being in your view controller class at all, but for a lack of anywhere else to put it. Or is that so?

Amidst the Table View, Label, and Button components in the Interface Builder object library is the simply named “Object” element. The description reads:

Provides a template for objects and controllers not directly available in Interface Builder.

“Not directly available in Interface Builder?” Then what’s the point, if we can’t do anything with it? Ah, but we can do things with it: we can hook up outlets and actions, and configure the objects with user-defined runtime attributes. We can, simply put, eliminate large swaths of glue code by letting the storyboard instantiate our coordinating classes for us, configuring them with connections to each other and to our views, and even allow us to tweak each object on a case-by-case basis. All with barely any code cluttering up our classes.

You might have a strong intuition that a lot of that belongs in code, as part of “your app.” If so, ask yourself: if this belongs in code, does it belong in this class? Truly? Cramming bits of orphan code wherever we can just to have a place to put them is a strong code smell. Storyboards help eliminate that. Embrace them.

Huge drawback: The objects you instantiate this way have to be @objc, and as such you can’t have @IBOutlets for a protocol type that isn’t also @objc. This means you lose the ability to pass and return non-Objective-C types such as structs, enums, or tuples. This is really frustrating and a significant limitation on using the technique to clean up your view controllers more generally.