Флаги функций (Feature flags) часто используются для контроля видимости новых функций в продукте. Существует несколько различных способов их внедрения, но самый распространенный — использование программного обеспечения для управления флагами. Самый простой способ, конечно, — это жестко прописать их, хотя о нем написано меньше всего.
Хотя программное обеспечение для управления фиче флагами может быть мощным, оно также является источником сложностей и рисков. Спам-маркетинг в блогах, стоящий за ним, настолько силен, что признать его ненужным — все равно что признаться в технологической импотенции. Мы убедили себя, что нам нужно не просто несколько флагов функций, а нужно масштабирование до тысячь. И не только это, но нам обязательно нужно изменять функции в рантайме, и мы должны делать это без развертывания, без перезапуска, без очистки кэша, без миграции базы данных, без проверки и без тестирования, потому что бизнес горит и единственный способ его потушить — это изменить цвет кнопки на главной странице.
Единственные флаги, которые должны стоят возможностей такой системы, относятся к изменению цвета. С точки зрения архитектуры, они представляют собой не более чем обычные инструкции if, управляемые отдельным процессом. Часто им требуется собственная инфраструктура, хостинг, мониторинг и все сопутствующие обязанности.
С точки зрения жизненного цикла разработки, они вносят недетерминированное поведение и усложняют рассуждения о коде. Долгоживущие флаги функций, хотя изначально и преследуют благие цели, приводят к техническому долгу, приводят к окостенению кодовой базы. Такой риск существует и при использовании жестко закодированных флагов, но его гораздо проще увидеть и контролировать.
С точки зрения безопасности они являются помехой, так как площадь поверхности для атаки или уязвимости теперь увеличилась.
В любом случае, добавление дополнительных движущихся частей в любую программную систему всегда должно тщательно проверяться на предмет того, действительно ли это необходимо и стоят ли риски, которые это создает, решаемых проблем.
Жестко прописанные флаги функций устраняют многие из этих проблем — они просты, надежны и безопасны. Это самый скучный способ сделать это, и именно поэтому он лучший.
Просто начните с простого JSON-файла, читайте его при запуске приложения и используйте для контроля видимости функций. Следите за флагами, удаляйте их, когда они больше не нужны. Если они живут слишком долго, сделайте их фактическим поведением и удалите флаг. Измените значение в ходе обычного процесса разработки, проведите его рассмотрение, тестирование и развертывание.
Для большинства команд и продуктов этого будет достаточно, и это уже большой путь. Когда команда действительно столкнется с необходимостью изменить функцию во время выполнения в масштабе, то, как и в случае с управлением состояниями в SPA, они поймут, что им это нужно.
Преждевременная оптимизация — не выход. Это плохой дизайн, плохая инженерия, и она хороша только для коротких моментов самодовольства на технологических конференциях, когда докладчик спрашивает, использует ли это кто-нибудь.