It is the kind of code that makes you squint. It could be that stray business logic in a controller, a view that queries the database, or even two intertwined features that change for different reasons. I am talking about code that is hard to read. Cryptic code slows everything down. It is the thing that makes a seemingly simple feature take weeks. Though we all can recognize unreadable code, it seems to keep showing up in our code-bases.

So I would have considered this crazy a few years ago, but I wrote my own mock framework in Elixir called ExDoubles. I know, I know, there are tons of them already, but hear me out. This one seeks to act like mock libraries in other languages, and put focus on the key element of abstraction in Elixir, the function. Why? Why? Why? I have been working in Elixir for the last six months, after years of Ruby and C#.

So you have written an implementation for that new feature in your Rails app, but your team won’t accept your Pull Request until there are unit tests. What’s more your changes are to private methods of a class. In frustration, you shout, “How do I unit test this code?” The key to unit testing private methods, in any language, is to test them through the public ones. Through almost two decades of practicing test-driven development, and writing unit tests in many languages at several large companies, including GitHub and Pivotal Labs, I have found you have only two strategies for maintainable unit tests around pre-existing private methods.

Since most applications can be represented by state machines, it is beneficial to make valid states in your program as clear as possible and invalid states impossible. This will enhance the readability, and maintainability of your code to everyone who sees it, including future you. In the rest of this article we will discuss one strategy for making invalid states impossible with an example in tsx and React. Replacing Booleans With Types Below you will find a tiny React component that displays fish from a fictional API.

Maintain shared behavior of multiple implementations by making them pass the same tests. Motivation When building a system, there may emerge a subsystem or class that has to share a baseline set of behavior with other implementations, while providing other non-functional requirements. The shared behavior can be shown to exist by using a contract test. Example Test doubles are a great way to reduce overall speed of the test suite by only running tests against in-memory versions of external services.

I built a small framework, which retaught me why it is important to understand a user’s problem, ship early and iterate. Yes, even for frameworks. It kicked off with a tweet, which expressed disdain for Ruby’s nil. The author yearned for a maybe implementation. Having just finished the Bowling Kata in Elm, a language which has a built-in Maybe type, I decided I could create a quick implementation. I didn’t anticipate how long quick was…

I want to tell you about an alternate design technique, it is called programming by intention. Rather than writing code that describes how to perform some action, you call a function. The interesting thing is the function doesn’t exist. Yet, we are going to call it as if someone wrote it ten minutes ago. We are going to follow a loop of call a function that doesn’t yet exist, implement what it does by calling more functions that don’t exist, until we have to implement the real code.

DRY is commonly interpreted to mean that code should not have duplicate structures. For instance two array indexes that both use rand(4) would be refactored away. Let’s look at an example of code that does exactly that. Person.new(names[rand(4)], jobs[rand(4)]) At some point, this is perceived as duplication and an abstraction is put in place. This abstraction is not logically consistent with the domain logic. Person.new(random_item(names), random_item(jobs)) At first this inconsistency is not inherently dangerous.

In the words of Jimmy Two Times, “I’m gonna go get the papers, get the papers.” The Don’t Repeat Yourself (DRY) Principle is commonly interpreted to mean, code with no duplicate statements. I’d like to explore that thinking with you for a few minutes so that I can demonstrate how it is flawed. I have written a small program that displays the name and job of randomly created people. Take a look at the :random_person function.