3 ms·
I'm always curious about Feature Flags - I'd love to use them. But they only seem to work if the interface doesn't change. From the example you gave: func
by marcus_holmes 6y ago
I'm always curious about Feature Flags - I'd love to use them.
But they only seem to work if the interface doesn't change. From the example you gave:
function reticulateSplines(){
if( featureIsEnabled("use-new-SR-algorithm") ){
return enhancedSplineReticulation();
}else{
return oldFashionedSplineReticulation();
}
}
All well and good as long as the enhancedSplineReticulation returns the exact same structure that the old one did. If it doesn't, then a bunch of code that handles the new reticulated splines also needs to be behind a flag (because the structure changed). And that could mean a chunk of UI needs to be duplicated behind a flag because it changed, and so on.
How do you use feature flags when the features aren't just trivial changes to methodology, but affect multiple parts of the system?
- markn951 6y agoCheck the flags in multiple parts of the system, or duplicate some logic and have two completely self-contained components, one with the new pieces and one untouched.
- marcus_holmes 6y agoYeah, I suppose so. But how do you deal with multiple feature flags implemented on the same piece of the system? How do you create discrete components when you have three or more features intersecting on that component? And presumably there's a proliferation of test cases, too (because you'd need to test that everything works with all combinations of features A,B,C,D implemented)? How much of this gets cleaned up afterwards? When the feature is fully rolled out, how do you resist the pressure to move on to another feature and leave the flags implemented rather than clean it all up and remove the old code?