How the Factory Pattern Can Reduce Technical Debt

By Solutions Engineer , Hacker Noon’s weekly sponsor, is the world’s leader in digital experience optimization, allowing businesses to dramatically drive up the value of their digital products, commerce, and campaigns through its best in class experimentation software platform. Optimizely enables product development teams to accelerate innovation, lower the risk of new features, and drive up the return on investment from digital by up to 10X.

Why this approach?

Experiments using Optimizely X’s Full Stack SDKs are typically implemented by using conditionals in your codebase to decide between feature variations. As experiments progress and clear winners from experimentation emerge this conditional code can create technical debt, once competing variations are no longer needed.

This method also creates dependencies between the variation conditions and experiment code since the if / else statements need to know the variation names in order to route the application to the appropriate code path.

This can become a problem, and I’m often asked by Full Stack users, what the best practice is for developing experimentation code that doesn’t leave sections of irrelevant code inside business logic and allows for additional flexibility when introducing new feature variations.

To achieve those goals, there are a few options to consider when implementing an experiment:

Standard Implementation: In Business Logic

Implement the feature variation and variation selection code within the business logic.

Pros

  • Easy to implement in the short term.

Cons

  • Creates technical debt within business logic.
  • Creates a coupling between if / else conditions and experiment configurations.

Alternative 1: Using the Factory Pattern

Abstract the feature variation selection code into a Factory class using the Factory Pattern.

Pros

  • Experimentation logic is kept separate from business logic, minimizing technical debt.

Cons

  • Still coupled with experimentation configuration.

Alternative 2: Factory Pattern Using Reflection

Further abstract the variation code by using Reflection in the Factory class.

Pros

  • Experimentation logic is kept separate from business logic, minimizing technical debt.
  • Generic enough to be reused across experiments, there is no direct coupling to variation names.
  • Increases flexibility for adding or removing feature variations.

Cons

  • Reflection adds overhead, reducing performance.
  • Not a feature available in all languages.

Experiment Setup

Let’s dig into each of these to see how each would look using a real world example. For instance let’s say we wanted to experiment with how we presented products to users with different sorting algorithms.

Using this example we’d setup an experiment in Optimizely Full Stack that would look something like:

Fig 1.


How the Factory Pattern Can Reduce Technical Debt was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Powered by WPeMatico