Transparent introduction of feature switches in projects

An article entitled "Better sustainable deployment with functional switches" was published in the previous Infoq column, which explains the integrated application of feature switches and spring. But if the project doesn't depend on spring, how do you better use the feature switches? At the same time, how to transparently introduce, so that the project does not rely entirely on the feature switch?

Next, I will combine our experience with the actual use of feature switches in our projects, and introduce a different approach to using feature switches to transparently implement feature masks.

Problem

Our team is developing an online insurance product that includes several brands, each with a different target user base, but with the same services. When the first brand is officially online, we face a big challenge-correcting bugs that are found on the line and continuing to add new features to other brands that are temporarily not reflected in the online brand. We are not willing to create a branch version of this multi-brand development because it is a disaster for version maintenance. Therefore, we decided to select the feature switch to solve the problem.

To solve this problem quickly, we can of course choose if ... else ... This simple characteristic switch model; However, other problems will be introduced:

Conditional special switches can have an impact on existing business structures

Clear business logic, simple code structure is the basis to ensure the maintainability of the project. If the addition of the feature switch makes the business logic complex and difficult to understand, then the feature switch destroys the maintainability of the project to some extent.

The code before adding an attribute switch is as follows:

Inputvehicledetails (); 
Createquote ();
Inputpersonaldetails ();
Buyinsurance ();

After adding the attribute switch:

Inputvehicledetails (); 
if (branda.isactive ()) {    //conditional characteristic switch
    createquote ();
}
Inputpersonaldetails ();
Buyinsurance ();
  

As you can see, a simple conditional branch implements an attribute switch--some code executes only when the condition is met, but it destroys the original clear business structure??

If some similar characteristic switches exist in the current program, conditional characteristic switches can cause logical confusion.

Before adding an attribute switch:

Inputvehicledetails (); 
Createquote ();
if (Currentbrand = = brandb) {    //original reliance on the criteria of the brand to Judge 
    Inputpersonaldetails ();
}
Buyinsurance ();
  

After adding the attribute switch:

Inputvehicledetails (); 
if (branda.isactive ()) {                //characteristic switch
    createquote ();
}
if (Currentbrand = = brandb) {    //original reliance on the criteria of the brand to Judge
    Inputpersonaldetails ();
}
Buyinsurance ();
  

It can be seen that the newly added conditional characteristic switch branda.isactive () is very similar to the original business decision logic Currentbrand = = Brasha, it is difficult to distinguish, and it is especially easy to confuse in the process of use. Worse, as the project continues to deepen, more and more conditional feature switches are placed in the code, and the code is filled with "bad taste", making the confusing situation worse!

Conditional feature switches do not have scalability

Conditional characteristic switches are usually simply conditional judgments and do not have scalability. Adding the first condition to judge and adding the tenth need to write as much code, and as the logic of judgment increases, the time and maintenance costs of adding code continue to increase.

For example:

if (branda.isactive ()) {        //characteristic switch
    inputvehicledetails ();
}
if (brandb.isactive ()) {        //characteristic switch   
    createquote ();
}
if (brandc.isactive ()) {        //characteristic switch
    inputpersonaldetails ();
}
if (brandd.isactive ()) {        //characteristic switch   
    buyinsurance ();
}