An interesting design idea

Writing Fewer Conditionals - Conditional statements are one of the first things we learn. We couldn’t write complex problems without the capability to branch the logic in different directions. Yet modeling conditionals too closely to the way we think can cause problems. In fact, they can be a major source of complexity when we’re writing complex logic. This article explores how good abstractions reduce the need for conditionals and make your code simpler.
 

A technique worth exploring

Don't Mock What You Don't Own - In the past few months I’ve been working with Go, a language that doesn’t have a lot in common with JavaScript. I’ve been rediscovering some concepts as a result of that. One of the first things I googled was how to mock an entire module. But the Go community favours manual dependency injection and it makes testing easier. In Node, mocking is the accepted practice, even though in other languages it’s considered a code smell. A good piece of advice is to mock only things that you own, meaning that you should wrap such functionality in your own function or module.
 

An article worth reading

Hexagonal Architecture in Netflix - As I said, I’ve been dabbling in other languages as of late. I think that moving away from JavaScript for a few months has actually made me a better JavaScript developer. I now see the patterns that we have adopted from other languages and we can learn a lot about architecture from them as well. Hexagonal architecture is an approach often applied when building microservices in Java or Go. It’s the best way I’ve seen to decouple domain logic from transport and data access logic. It’s worth exploring even if you don’t agree with the design it proposes.
 

A talk worth watching

A Philosophy of Software Design - I really like John Osterhout’s ideas for better software design. They give a different angle than the commonly accepted “Clean Code” and I find them to be much more practical. He tackles the topic on a more fundamental level. It’s not just about writing well-structured code, it’s about deconstructing problems in a good way. The ideas in the talk are abstract but that makes them applicable in many different environments. I’ve been using the “write deep modules” rule when working with React components for years now.
 

An idea to ponder

Dynamic Type Systems are Not More Open - Eight years ago I started my programming journey with C#. When I moved away from typed languages I felt my hands getting untied. Dynamic languages gave me more freedom and helped me create faster. But this article raises an important question. Can we actually develop without types? Because each time we access a field on an object, we assert that its type has this field. When we use a method on a variable we assert it has implemented it. The types are always there, but in dynamic languages, they are in the implementation.
 

A quote worth thinking about