Indirection Is Not Abstraction
The concept of abstraction in software development is frequently misunderstood and confused with indirection. This is partially because of the keywords
interface in statically-typed languages such as Java and C#. The confusion often leads to design changes that leave the code worse than before it was touched. Let’s look at how abstraction and indirection relate, and how to correctly connect components.
Elegant A/B Tests
Flexible software systems are a pleasure to modify. You know that you have a flexible system when you can change the behavior of the system without changing any existing code. Adding a new behavior should simply require adding new code. I will show you how to easily introduce A/B tests along with a new feature, without changing the existing code.
Test Failures Are Critical Bugs
In a mature software project, tests are what enable risk-free, rapid development. They are the only thing that truly enables Continuous Integration and Continuous Delivery for software that is deployed directly to end users. In order to keep delivering, those tests must be kept pristine, and any failure represents a critical flaw which must be immediately addressed. Every test failure that happens outside of new feature development on a developer’s box, must result in a Bug Ticket. No exceptions!
If you’re familiar with software design patterns, you’ve probably encountered Factory Methods, Factory Classes, Abstract Factories and other creational patterns that are used to encapsulate details of the construction of a polymorphic object. All of these patterns are great, and solve very specific problems, but one of the flaws is that they always add indirection between you and the object that you actually want to use. I would like to introduce you to Factory Objects, which eliminates indirection completely.