Сообщить об ошибкеКороткий ответ
Нужно ввести обязательные метаданные для каждого флага (владелец, дата создания, назначение, плановая дата удаления), регулярный аудит (отчёт по флагам старше N месяцев) и процесс «очистки» — после полной раскатки функциональности флаг и связанный с ним мёртвый код должны удаляться отдельным технически простым PR, а не оставаться навсегда.
Как это работает подробнее
feature flag management платформы (LaunchDarkly, Unleash, собственное решение) обычно позволяют хранить метаданные флага и его тип (release flag — временный, kill switch — постоянный, permission flag — долгоживущий), что сразу задаёт ожидания по сроку жизни. Release-флаги по умолчанию должны иметь срок годности.
Пример кода
example.json
{
"key": "new_checkout_flow",
"type": "release",
"owner": "team-payments",
"created_at": "2024-01-15",
"planned_cleanup_by": "2024-03-15",
"rollout": "100%"
}Что использовать на практике
- На практике. полезно встроить в пайплайн или в еженедельный отчёт проверку «стейл» флагов — тех, что включены на 100% везде дольше определённого срока, и заводить тикеты на их удаление. Важно различать типы флагов: kill switch для аварийного отключения функциональности может жить годами осознанно, а release-флаг для раскатки конкретной фичи должен исчезнуть вскоре после полного релиза.
- Пример. Ожидаемое поведение: автоматический отчёт показывает, что флаг `new_checkout_flow` раскатан на 100% уже больше планового срока очистки, и создаёт задачу команде `team-payments` на удаление флага и упрощение кода.
Подводные камни
- Частые ошибки. относятся ко всем флагам одинаково, не разделяя временные и постоянные, из-за чего непонятно, какие можно безопасно удалить; удаляют флаг из системы управления, не убирая условную логику из кода, оставляя мёртвые ветки и путаницу для следующих разработчиков.