Хардкодить фича-флаги — это нормально
It's OK to hardcode feature flags (2025)
Автор утверждает, что для большинства команд и продуктов достаточно простых хардкод-флагов, а не дорогих систем управления фича-флагами. Такие системы добавляют сложность, риски для безопасности и недетерминированное поведение, а также ведут к техническому долгу. Он предлагает начинать с JSON-файла, читаемого при запуске, и удалять флаги, когда они больше не нужны. Переход на полноценное управление флагами оправдан только тогда, когда действительно требуется менять поведение в рантайме в масштабе.
Они — самый скучный способ сделать это, и именно поэтому они — лучший способ.
- jameshart
По моему опыту, эти два подхода (фича-флаги на основе конфигурации и сервисы фича-флагов) на самом деле являются двумя взаимодополняющими возможностями, которые решают две совершенно разные проблемы, но случайно имеют одно и то же название: фича-флаги.
Подход с конфигурацией критически важен для использования фича-флагов как инструмента жизненного цикла разработки ПО. Именно так вы управляете кодовой базой, которая содержит незавершённый код новой функции X, но при этом может быть развёрнута и проходить все тесты без включённой функции X.
В этой модели нужен механизм, который позволяет разработчику, работающему над функцией X, включить её для локального тестирования, а вашей CI-системе — взаимодействовать с системой флагов, чтобы проверить, что приложение работает в обоих состояниях — с включённой и выключенной функцией X.
Это идеально для моделей разработки на основе trunk; фича-ветки — это альтернативный подход, который не получает особой выгоды от этого (более того, это добавляет сложности при работе с фича-ветками).
Между тем сервисы фича-флагов решают проблему, когда разным пользователям одного и того же ПО нужно включать разные функции. Это может быть так же просто, как внутренние тестировщики или бета-пользователи, может означать удержание функций до запланированных окон обновления для каждого тенанта, или это может быть частью стратегии управления рисками, когда функции внедряются через постепенное расширение аудитории.
Также может возникнуть соблазн смешать систему фича-флагов с системой A/B-тестирования — вы можете использовать сервис фича-флагов, чтобы показать функцию тестовой когорте и […]
- jdwyah
Я участвую во втором стартапе, связанном с фича-флагами, но я отчасти согласен с этим.
В каждом проекте должны быть флаги, но многим проектам нужен только базовый функционал, и сервис — это излишество.
Создание собственного JSON по-прежнему кажется тем, чего стоит избегать. Да, на старте это на 95% булевы значения. Но потом вам нужен постепенный rollout. Потом нужны правила таргетинга. Потом нужны небулевы значения… может, немного JSON. О, разве не было бы здорово, если бы JSON мог соответствовать схеме… и в конце концов вы понимаете: чёрт, я действительно хочу менять это без деплоя. Или вы хотите читать один и тот же флаг из нескольких сервисов.
Я пытался включить этот общий знаменатель в https://quonfig.com. Используйте его совершенно бесплатно и с открытым исходным кодом как SDK — это просто загрузка JSON, который можно отслеживать в git. Агентам это нравится, горячая перезагрузка, SDK на многих языках. Но по сравнению с созданием собственного решения у вас много свободы в дизайне. Множество операторов таргетинга. Сегменты и т.д. А если вы всё же захотите получить хороший UI / сеть доставки для обновлений в реальном времени, то можно использовать платную сторону.
Описание локального использования: https://docs.quonfig.com/docs/how-tos/open-source-local
- avlcodemonkey
Если вы работаете с C#, Microsoft добавила первоклассную поддержку управления функциями в .NET с помощью https://github.com/microsoft/featuremanagement-dotnet. Он предоставляет логику для простого вкл/выкл, таргетинга пользователей, процентных rollout'ов и расписаний. Использование управления функциями вместе с флагами, захардкоженными в `appSettings.json`, имеет смысл для более простого приложения.
Когда ваша архитектура растёт и вам нужно синхронизировать конфигурацию между несколькими приложениями или дать возможность нетехническим пользователям менять флаги, тогда вы, вероятно, переросли хардкодинг и вам стоит рассмотреть создание (или покупку) сервиса. Вам, скорее всего, не захочется, чтобы владельцы продукта пытались задать переменную окружения типа `FeatureManagement__NewFeature__EnabledFor__0__Name`. Azure App Configuration — это вариант, если вы готовы использовать Azure — он предоставляет удобный UI для редактирования флагов вместо работы с JSON. Или, я создаю https://featureflags.app/ как альтернативного провайдера, если вы предпочитаете держаться подальше от Azure. Это что-то вроде золотой середины между хардкодингом и полноценной платформой вроде LaunchDarkly.
- maxidog
Я сейчас занимаюсь реверс-инжинирингом большого корпоративного приложения, и раздутость фича-флагов просто поражает. На мой взгляд, чрезмерная сложность фича-флагов — это симптом руководства, которое нерешительно и которому не доверяют разработчики.
- stronglikedan
Если только вы не Knight Capital, конечно. https://www.youtube.com/watch?v=UuqSy1jPSUw