Как аналитику понять, что нужен фичатогл для фичи?
Для того, чтобы прописать в документации о необходимости фичатогла аналитику необходимо понять минусы и плюсы.
Плюсы и минсуы
Плюс - задача хорошо декомпозирована и мёржится небольшими порциями
Минусы
- постоянные merge-конфликты в основной ветке, которые вам потребуется разрешать
- сложность тестирования: при выходе нового релиза, QA инженеры тестируют все фичи, которые в него входят, а также пробуют включать и выключать их, используя feature switcher-ы. Это требует большого количества дополнительного времени, так как желательно протестировать всевозможные комбинации флагов
-появление мёртвого кода: значения многих feature toggle-ов не меняются на протяжении длительных промежутков времени или не меняются вовсе, и таким образом код, написанный для другого значения флага, фактически становится «мёртвым»
Как решать минусы:
- чтобы понимать, какой эффект имеет тот или иной фичатогл и по какому ключу его искать в базе данных, следует создать подробную документацию с описанием всех фичатоглов.
- чтобы избежать появления “мёртвого” кода, нужно периодически удалять устаревшие фичатоглы и связанный с ними код
Как прописать фичатогл в документации:
Название фичатоглов продумывает аналитик, в компании может быть стандатизировано название, пример фичатогла на добавление экрана подписания документов для кредита наличными в мобильном приложении банка:
mbios_17899_signed_documents_cashloanflow
mband_15894_signed_documents_cashloanflow
где mbios_17899 - номер задачи в Jira, а igned_documents_cashloanflow - описание фичи, причем фичатогл описывается на каждую мобильную платформу
Для того, чтобы прописать в документации о необходимости фичатогла аналитику необходимо понять минусы и плюсы.
Плюсы и минсуы
Плюс - задача хорошо декомпозирована и мёржится небольшими порциями
Минусы
- постоянные merge-конфликты в основной ветке, которые вам потребуется разрешать
- сложность тестирования: при выходе нового релиза, QA инженеры тестируют все фичи, которые в него входят, а также пробуют включать и выключать их, используя feature switcher-ы. Это требует большого количества дополнительного времени, так как желательно протестировать всевозможные комбинации флагов
-появление мёртвого кода: значения многих feature toggle-ов не меняются на протяжении длительных промежутков времени или не меняются вовсе, и таким образом код, написанный для другого значения флага, фактически становится «мёртвым»
Как решать минусы:
- чтобы понимать, какой эффект имеет тот или иной фичатогл и по какому ключу его искать в базе данных, следует создать подробную документацию с описанием всех фичатоглов.
- чтобы избежать появления “мёртвого” кода, нужно периодически удалять устаревшие фичатоглы и связанный с ними код
Как прописать фичатогл в документации:
Название фичатоглов продумывает аналитик, в компании может быть стандатизировано название, пример фичатогла на добавление экрана подписания документов для кредита наличными в мобильном приложении банка:
mbios_17899_signed_documents_cashloanflow
mband_15894_signed_documents_cashloanflow
где mbios_17899 - номер задачи в Jira, а igned_documents_cashloanflow - описание фичи, причем фичатогл описывается на каждую мобильную платформу