5

Feature toggling works perfectly for a new functionality - in most cases the functionality should be simply surrounded with some UI container that will be visible or not based on feature configuration. But how feature toggling could be used if a new feature requires massive changes in existing code base? I can not use 'copy & change', because obviously it is much worse than feature branching - I'll not get any merge conflicts. So what are the best practices for such requirements?

Ian Ringrose
  • 51,220
  • 55
  • 213
  • 317
Sane
  • 2,334
  • 2
  • 17
  • 20
  • Can you just hide all controls associated with the 'old' feature you want to make toggling? Or move them into a new UI container. In WinAPI, for example, this is simply creating a list of controls and do SetParent SetWindowPos. – exebook Feb 11 '13 at 05:06

1 Answers1

1

You can combine feature toggling with an IoC container to load different implementations of your components. For example, toggle "A" loads implementation "X" while toggle "B" loads implementation "Y". This approach would permit you to maintain parallel implementations and turn on legacy and new functionality based on a single toggle.

Ed Chaparro
  • 313
  • 4
  • 13
  • There is two issues with such approach. The first one is that bugs fixed in legacy code could be not fixed in new code (unit tests could help here, though). But second and a major issue is that before creating new implementation the old one should be rewrote (not even refactored). – Sane Mar 26 '12 at 13:41