Фича тогл что это
Тогл Toggle
Тогл переключает состояния. Например, включает или отключает уведомления в настройках.
По-английски toggle — рычаг или переключатель. Между собой мы говорим «тогл», чтобы не путать этот контрол с радиокнопками или табами-переключателем. Тем не менее при общении с пользователями мы говорим не «тогл», а «переключатель».
Когда использовать
Функционально тогл — аналог чекбокса, но контекст их использования может отличаться.
Тогл заимствован из мобильных операционных систем, где он используется для включения и выключения настроек.
Тогл нельзя использовать для выбора элементов в списке. Например, выбрать несколько писем.
Тогл больше и заметнее чекбокса. Хорошо, когда на странице 1 тогл, максимум 2–3.
Описание работы
Чтобы переключить тогл, нужно кликнуть на сам контрол или его название.
При переключении тогла эффект наступает сразу. Поэтому тогл не нуждается в кнопке «Сохранить».
Расположение
В отличие от чекбокса, тогл может располагаться как слева, так и справа от названия. Если тоглов несколько, лучше их ставить слева от текста.
Цвет тогла во включенном состоянии — как у чекбоксов, радиокнопок и ссылок. Можно использовать фирменный цвет, для всех тоглов в сервисе. Можно использовать позитивный цвет там, где этого требует сценарий.
Валидация
Если тогл нельзя использовать, заблокируйте его. Валидация не нужна.
Дизайн и анимация
Тогл переключается с анимацией. Круг плавно перемещается, фон движется за ним:
Активное состояние — стандартный синий цвет #1F87EF. Выключенное — серый #F6F6F6 по умолчанию и #D6D6D6 для выбранного.
Feature toggle
Подготовил репку с примерами, смотреть тут.
Предыстория
Мне нравится англоязычный подкаст по iOS-разработке iPhreaks, и в один прекрасный момент я набрел на соседний рубевый подкаст про feature toggles. Все началось с легкого наброса про то, что не стоит ребейсить, продолжилось про интереснейший подход к ведению веток TBD и закончилось feature toggles.
Само знакомство с последним подходом стало для меня некоторым откровением. Причина скорее всего в том, что самому приходилось удалять фичи, которые были реализованы несколько месяцев назад, причем это делалось с муками и болью, а тут мне предложили отключение фич по щелчку пальцев, да еще и наобещали A/B тестирования с удаленным управлением фичами.
На первый взгляд кажется, что инкапсулировать фичи, для последующего их переключения довольно просто, но чаще всего это не так. Кучу раз встречался со случаями, когда фича имеет выключатели в куче мест, они находятся на всех слоях приложения, вдогонку само отключение фичи вызывает веселые сайд-эффекты.
В процессе подготовки читал разные источники, но ключевым стал этот пост в блоге Фаулера, там автор разбирает данный вопрос с примерами из js, я же попробовал адаптировать это к реалиям iOS-разработки, естественно, ничего теоретически нового я не придумал.
Забегая вперед, напишу, что позже с этой темой я выступил на локальной Рамблеровской конфе Rambler.iOS, а потом и на питерской Mobius. Надо сказать, что как раз на последней народ принял довольно прохладно, и в комментах было и про банально, и про то что не надо, а если надо, то делается просто. Отдельно были комменты про скомканный материал(мы с коллегой решили уместиться в один слот, чтобы народ не скучал, видимо получилось слишком бодро) и про то, что слишком много теории, нужна практика и примеры.
Про просто я не согласен(иначе не встречался бы код где переключение фичи размазано по всему приложению), а вот недостаток практики и примеров попробую исправить. Кто уже устал читать может глянуть сразу в пример на github.
Теория
Концепция
В данном подходе есть несколько основных моментов:
Категории фич
В том самом посте из блога Фаулера, довольно долго расписываются категории с диаграммами Венна, я же предложу ровно две: статические и динамические. Именно эти ровно потому, что для них есть принципиальное различие в плане реализации.
Статические
К статическим относим фичи, о состоянии, на которое они опираются, известно заранее. Например нам надо что-то отображать в зависимости от размера экрана, или от версии операционной системы, или от начального конфига приложения. Во всех случаях к моменту создания модуля уже известно состояние, или оно меняется снаружи и сам модуль выступает в пассивной роли. Далее можно действовать двумя способами: передаем снаружи некий конфиг, или правильно настраиваем зависимости(например подставляем in-Memory хранилище вместо CoreData). В этом случае класс получается самодостаточным и ему никто не нужен для определения собственного поведения.
Динамические
Тут находятся фичи, о ключевом состоянии которого нам всегда необходимо знать, обычно это состояние может меняться множество раз за время жизни нашего компонента. Например мы хотим дизейблить кнопку, если есть интернет соединение, и включать обратно, если есть. Также хотелось бы инкапсулировать логику по принятию решения в отдельный объект, чтобы не тащить все необходимые для этого зависимости в сам класс.
Примеры
И наконец примеры! Давайте разберемся как это все будет выглядить на реальных примерах. Отдельно напишу, что подготовил для вас репозиторий со всем кодом, который был использован в примерах.
Для простоты понимания и чтобы абстрагироваться от какой либо конкретной архитектуры, буду использовать MVC + FeatureService, для принятия решения о включенности динамических фич. Вот теперь точно поехали!
Статические
Пример 1 (Передача конфига)
Как будет выглядить ветвление логики внутри:
Тут все довольно просто, нам передали конфиг, мы его сохранили в свойство, каждый раз когда нам надо принять решение, просто смотрим на соответствующие свойства.
Пример 2 (Настройка зависимостей)
У нас есть табличка, где мы отображаем список постов, туда мы хотим подмешать рекламу. Контроллер сам ничего не грузит, а получает все данные у своих провайдеров:
Мы просим данные у провайдера статей и у провайдера новостей, если второго нет, мы просто ничего не получим, все довольно просто:
Как и в первом случае место управления фичей находится за пределом модуля, да еще в случае с зависимостями не требуются ни проверки, ни места ветвления, все работает само.
Пример 3 (Сервис настроек)
Представим, что при заходе на экран нам надо показывать полноэкранную рекламу, но не чаще раза в сутки.
FeatureServiceViewController.m:
Контроллер обращается к специальному сервису за этими знаниями и действует в соответствии с ответом. Как выглядит сервис внутри:
FeatureServiceImplementation.m
Сервис содержит в себе все необходимые зависиомти для принятия решения. Иногда ему также требуется передавать некоторые параметры из контроллера.
Еще больше подробностей
Теперь когда мы посмотрели на примеры можно обсудить преимущества данного подхода и некоторые моменты, которые сразу не бросаются в глаза. В особенности это касается динамических фич.
Отсутствие логики принятия решения в VC
Место ветвления
Есть несколько моментов от которых хотелось бы предостеречь
Избыточная инкапсуляция
Данный подход может привести к желанию использовать его всегда, но не стоит делать каждую фичу выключаемой:
Зависимые фичи
В идеале лучше не иметь зависимых фич, но в случае, если этого не избежать, надо стараться уменьшать уровень зависмости. В качестве примера зависимых фич можно привести авиарежим и настройки связанные с получением данных. Если включен авиарежим, не имеет значение что в них выбрано.
Что получаем?
Итоги
Подход довольно простой, но в то же время он формализует множество важных моментов, которые с одной стороны лежат на поверхности, когда на них смотришь, но которые можно забыть во время реализации. Я реализовывал нечто подобное и раньше особо не задумываясь, но знакомство с подробностями данного подхода уложило в голове как можно инкапсулировать фичи и то от чего стоит продостеречься.
Напишите мне в комментариях или мне в twitter, что думаете. Буду признателен за фидбек.
Что такое feature toggle или как избавиться от мучительных мёржей и долгоживущих веток?
Проблема
Представьте, что циклы разработки вашей команды длятся по две недели, а реализация новой фичи потребует от команды 3 месяца разработки. На первый взгляд, есть две возможные схемы действий:
Использование feature switcher-ов для решения проблем
Такая проблема встречается в разработке довольно часто и есть изящное решение, позволяющее взять лучшее от описанных выше подходов — feature toggle или feature switcher.
По сути, feature switcher — это boolean флаг, который хранится в базе данных и содержит информацию о том, должна быть включена та или иная фича или нет. Значение этого флага может быть извлечено из базы данных по ключу. Удобство использования feature switcher-ов заключается в том, что они могут быть легко изменены бизнес-пользователем во время runtime через панель администратора без необходимости заново деплоить приложение.
Ниже приведен пример использования feature toggle на языке Java:
В примере выше configurationManager — это класс, позволяющий извлечь значение определенного feature switcher-а из базы данных по его ключу.
Также, при помощи feature switcher-ов, можно отображать/скрывать определенные элементы на фронтенде. Для этого придется положить значение флага в Model и передать его на View как это показано ниже:
После чего использовать переданное значение для рендеринга того или иного HTML кода:
Виды feature switcher-ов
Описанный концепт использования feature switcher-ов — это лишь один возможный случай использования и такие feature switcher-ы называются release toggles. Всего выделяют 3 разных вида feature switcher-ов:
Проблемы использования feature toggle-ов
Поскольку я работаю на проекте, где активно используются feature toggle-ы, то кроме очевидных достоинств их использования я начал замечать и проблемы, связанные с ними:
Решения некоторых из описанных проблем
Помочь решить вышеописанные проблемы могут следующие действия:
Итоги
Feature switcher — очень простой и одновременно мощный механизм, позволяющий избегать монструозных коммитов, легко менять поведения приложения или собирать несколько разных приложений на одной кодовой базе, используя разную конфигурацию feature toggle-ов.
Однако, стоит также помнить, что этот паттерн разработки имеет некоторые недостатки, которые выливаются в трудночитаемый и трудно поддерживаемый код, поэтому следует избегать чрезмерного использования этого паттерна и периодически проводить документирование feature switcher-ов и их ревизию, чтобы удалять неиспользуемые и, как следствие, очищать проект от “мёртвого” кода.
Тогл-принцип в интерфейсах
Пост в двух словах: анализируем, какие панели ключевые для программы. Скрываем ненужные, на нужные назначаем горячие клавиши, начинающимися на Alt + Cmd. Используем мнемонику, чтобы запоминать английские имена панелей: Alt + Cmd + I(nspector), Alt + Cmd + L(ayers). Переназначим все горячие клавиши так, чтобы одни и те же ассоциации срабатывали в разных программах. Позабудем про печаль и боль, умело смеёмся.
Как настраивать свои горячие клавиши в Скетче и не забывать их
И почему так важно назначать горячие клавиши для работы с символами.
Я хочу поделиться важной идеей, которая позволила мне выстроить единую систему горячих клавиш в своей работе. Если ты примешь её, то сможешь в считаные минуты ориентироваться в любых профессиональных редакторах, вне зависимости от их назначения и кажущейся сложности. Sketch, Photoshop, Illustrator, Pages, Axure, Final Cut, After Effects и кончая какой-нибудь Ableton Live или Logic Pro.
Все они используют один и тот же дизайн-паттерн — скрываемые панели.
To toggle (от англ.) — переключать что-либо, что может быть в двух режимах: включено/выключено. Нажал раз — включил, нажал два, выключил. Например, панель слоёв в Фотошопе или сетка в Скетче может быть видима, либо скрыта.
Я иногда натыкаюсь на горячие клавиши, которые следуют тогл-принципу. Не я его придумал. Однако, я не встречал ни одной программы, в которой этот принцип был изначально реализован без переназначений горячих клавиш.
Вам не нужно изучать интерфейс в деталях, а нужно понять, как сделать так, чтобы он не мешал лишними кнопками и панелями, и показывал то, что действительно необходимо для решения вашей текущей задачи. Если ты не используешь какую-то панель прямо сейчас, значит она загаживает интерфейс и снижает фокус внимания.
Идея 1. Что-то скрываемое
Эту идею легко можно довести до абсурда. По интернету гуляла смешная картинка с интерфесом текстового редактора Word, в котором включены все панели, которые в нём только есть:
Это не значит, что у Word был плохой дизайн. Напротив, тогда он предоставлял неслыханную гибкость опытным пользователям. Каждый мог включить в настройках то функциональный набор, который был нужен. Однако, такой уровень несёт опасность для начинающих пользователей. Большинство пользователей Word просто не знало о том, что в его контекстном меню скрыто ещё множество панелей. А чтобы научиться ими пользоваться, нужно читать унылую документацию. Если какая-нибудь важная панель, например Форматирование, исчезала из поля зрения, это могло стать настоящей драмой, поскольку Word воспринимался как сломанный.
Итак, первый из наших ингрединетов — скрываемые панели, содержащие какие-либо UI-кнопки.
Идея 2. Горячая клавиша в режиме on/off
Я впервые столкнулся с тогл-панелями в Фотошопе. Я узнал, что по нажатию F7 панель слоёв можно скрывать. Сперва это показалось довольно бессмысленным: очередная незапоминаемая горячая клавиша, которая скрывала маленькую квадратную панель среди полдюжины других. Но позже я выяснил, что панели в Фотошопе можно настраивать по размеру, делая нужные больше и убирая ненужные. Когда самая важная для веб-дизайна панель «Слои» занимала всю высоту экрана, она значительно загораживала макет, и я её регулярно скрывал, чтобы не мешала. Однако, размножить этот принцип на другие панели не удавалось. Я еле-запомнил F7, начертив её перманентным маркером на руке и развесив по всему дому стикеры-напоминалки. Бессмысленные горячие клавиши невозможно запоминать, если не используешь программу регулярно.
Минус упомянутого дизайна Word заключался ещё и в том, что его тогл-панели нельзя было сделать видимыми при помощи клавиатуры. Каждый раз пользователю приходилось лезть в контекстное меню и ставить галочку напротив нужной панели, чтобы сделать её видимой. Фотошоп решил эту проблему, хоть и очень криво.
Второй ингредиент — горячая клавиша, которая переключает видимость панели туда-обратно.
Идея 3. Используем мнемонику
Горячая клавиша — это не про безумные вытягивания пальцев по клавиатуре, не про запоминание семизначных чисел.
Прежде всего, горячая клавиша это приказ программе в обход графического интерфейса.
В этом её гигантское недооцененное преимущество. Дизайн программы может измениться, новая иконка собъёт с толку, но смысл команды и её название останется прежним.
Чтобы можно было запомнить команду, она должна вызывать человеческие ассоциации и быть понятной. Те, кто выпускает ПО со стандартными горячими клавишами вроде F7, совершают преступление против человечества, поскольку из-за них миллионы людей боятся использовать горячие клавиши, и особенно, переназначать стандартные.
Поскольку у меня стоял английский Фотошоп, панель слоёв в нём называлась Layers. Логично, что я назначил на неё Cmd + L(ayers). Однако, в Фотошопе было много команд, которые имели такой же вид: Cmd + D — Deselect, снятие выделения. Cmd + C и Cmd + V — всем известные копирование и вставка, и ещё множество других. Все они являются командами, которые ведут к каким-то заметным действиям на холсте. Я называю их действиями. Скрытие панели Layers в этом ряду явно было белой вороной. Решение подсказал текстовый редактор Pages, в котором основная панель Inspector скрывалась и показывалась по сочетанию Alt + Cmd + I. Я взял это на вооружение в Фотошопе, а позже и в Скетче.
Пазл сложился: все тогл-сочетания отныне получили вид Alt + Command + [буква].
Теперь однотипные панели вроде Inspector в разных программах автоматически получают постоянное универсальное сочетание.
Пять основных паттернов
Так я разделил горячие клавиши на группы-паттерны по внешнему виду:
В каждом паттерне присутствует ключ (буква).
Тогл-панели
Alt + Cmd + ключ. Умение эффективно использовать тогл-панели — мощнейшая техника, превращающая интерфейс в податливый пластилин на кончиках пальцев. Примеры: Скрыть/показать панель Inspector ( Alt + Cmd + I), скрыть Library в Logic Pro X ( Alt + Cmd + L).
Тогл-режимы
Ctrl + [ключ] — Эту группу я выделил после перехода на Скетч. Есть много действий, которые имеют сходную природу с тогл-панелями, но не выглядят как панель. Примеры: Включить сетку ( Ctrl + G), перейти в режим вращения объектов ( Ctrl + R), замьютить канал в аудио-редакторе ( Ctrl + M).
Инструменты
[ключ] — выбор инструмента. Скетч отлично использует такие горячие клавиши. Примеры: O — Oval Tool, V — Vector Tool, T — Text Tool. Photoshop в более сложном положении, поскольку инструментов в нём гораздо больше. Однако, и в нём это используется: M — Marquee Tool, L — Lasso Tool, B — Brush Tool.
Важные действия
Cmd + [ключ] — команда-действие. Вырезать, выделить, покрасить, переименовать и редактировать — это всё сюда.
Обращения
Shift + Cmd + [ключ] — тут два варианта. Либо парная обращающая команда (Сгруппировать/Разгруппировать), либо ещё один слой команд-действий.
Пример из Скетча, обращение:
Cmd + G — сгруппировать,
Shift + Cmd + G — разгруппировать.
Cmd + Z — отменить,
Shift + Cmd + Z — повторить отменённое действие.
Идея 4. Метод перебора букв
Букв явно меньше, чем команд. Буква S на клавиатуре всего одна, и по такому принципу в Фотошопе на неё претендуют сразу две панели: Swatches и Styles. И тут нам решать, что займёт основное сочетание Alt + Command + S. Что нам нужнее? Допустим, нужно много работать с цветами, поэтому выбираем Swatches. Второе сочетание может разместиться на следующей букве слова.
[S] T Y L E S — S занята Swatches, выбираем следующую букву.
S [T] Y L E S — T свободна. Получили Alt + Cmd+ T.
Как правило, хватает первых трёх букв слова. Если мы дошли до конца слова STYLES и все буквы заняты, возможно, эта панель не настолько важна, чтобы назначать на неё горячую клавишу. Либо придётся освободить уже занятые буквы.
Не держись за ключ
Не стоит стремиться сохранить букву, дополнив тогл-группу какой-нибудь посторонней клавишей типа Shift, потому что это ведёт к незапоминаемым монстрам: Shift + Alt + Cmd+ S, которые придётся зажимать всем офисом. Не надо так.
Если по ошибке вместо Alt + Cmd+ T мы нажимаем Alt + Cmd + S, развернув панель Swatches вместо Styles, ошибку легко исправить, нажав Alt + Cmd+ S снова и не отпуская клавиш Alt + Cmd, нажать следующую букву нужного названия панели, словно мы печатаем слово Styles.
Какие плюсы даёт следование тогл-принципу
Ты используешь память
Если их назначить один раз, твои горячие клавиши работают в любых программах для Mac. Не нужно запоминать, что в Скетче панель слоёв открывается Alt + Cmd + 1, а в Photoshop — F7. В обоих программах можно поставить одну клавишу: Alt + Cmd + L(ayers).
К слову, в Скетче я оставил Alt + Cmd + 1, потому что это легко было запомнить по другой логике: панель 1 слева, панель 2 справа.
Ты экономишь время
И не тратишь его на зрительное запоминание интерфейсов и рассматривание иконок, а обращаешься напрямую к первичному смыслу, ради которого используешь продукт.
Ты группируешь команды по смыслу
По внешнему виду горячей клавиши ты можешь понять, к какой группе она относится.
Ты используешь знакомые слова для подсказок
Читая названия панелей в интерфейсе программы, ты всегда можешь посмотреть, на какую букву они начинаются, зажать тогл-группу Alt + Cmd и добавить нужную букву. Либо, если нужная панель скрыта, посмотреть в меню программы. Поиск по меню в пункте Help работает на отлично.
Минусы тогл-подхода
Психологический барьер
Тебе придётся перешагнуть через серьёзный психологический барьер, научиться переназначать горячие клавиши и понять, что в этом нет никакого криминала. Это сложнее, чем кажется.
Придётся что-то настраивать, вместо того чтобы делать работу
Когда ты открываешь новую программу, первые 10 минут вместо работы тратишь на настройку. Впрочем, они окупятся.
Не хватит букв
Если нужно действительно много тогл-панелей в сложной программе, могут закончиться буквы. В этом случае придётся отойти от канонического Alt + Cmd и заменить его на Ctrl + Cmd, что нарушает стройную идиллию и слегка рушит мозг.
Что если в программе нельзя назначать горячие клавиши?
Значит, это хреновая программа. Найди хорошую. Либо напиши разработчикам, чтобы вынесли нужную функцию в основное меню. Часто независимые разработчики слушают пользователей. Если ты программист — напиши хорошую самостоятельно. Хватит это терпеть!
Переключатель функциональности — это инструмент, позволяющий переключаться со старой функциональности на новую, не пересобирая приложение и не выпуская его заново. Реализуется добавлением в код условного оператора ( if ), который дает возможность управлять поведением программы, просто меняя нужное значение в конфигурационном файле или базе данных. Если вы хоть раз редактировали настройки в ini-файле, то вам знакома эта технология.
Копнув поглубже, можно обнаружить огромное количество разных вариантов переключателей и новых возможностей, которые они предоставляют. Это вызывает много вопросов. Где размещать конфигурацию? А что делать, если она станет недоступна? Наверное, можно и самому написать простенький каркас для работы с переключателями? Может, лучше взять готовое решение? А это подходит и монолиту, и микрослужбам?
Общие сведения о переключателях функциональности
Что это
Говоря по-простому, смысл переключателей состоит в следующем. Исполнитель продвигается по нашему коду, представляющему логику предметной области, и натыкается на условный оператор. В этом операторе исполнитель спрашивает, нужно ли выполнять обусловленный код, у какого-то реестра, которому известно, когда и при каких обстоятельствах интересующая функциональность должна работать.
В результате исполнитель идет либо по одной ветке, либо по другой, а в вырожденном случае другая ветка просто пустая. В простейшем случае переключатель принимает одно из двух значений («включено» и «выключено») под управлением ответственного лица, которое ведет реестр. А можно придумать и что-то посложнее, например включать функциональность только для конкретных пользователей или для пользователей из определенных стран, или в определенное время.
Реестр функциональности может иметь разную форму. Смысл появляется, когда управлять этим реестром можно не останавливая приложение и не развертывая его заново. К примеру, переключатели можно хранить в файле, в базе данных или иметь отдельную сетевую службу с переключателями. Ниже работа переключателей рассматривается подробнее.
Это вообще актуально?
В своей статье создатель featureflag.tech утверждает, что переключатели становятся стандартной практикой в разработке ПО. Появляется все больше материалов о переключателях: теоретические статьи, рассказы о практике внедрения переключателей, доклады на конференциях. Я включил ссылки на самые интересные материалы в текст данной статьи; все ссылки собраны в разделе «Заключение».
Я сказал бы, что росту популярности переключателей способствует стабилизация и стандартизация в некоторых областях информационных технологий. В «кровавом энтерпрайзе» появляется все больше островков стабильности. Увеличение числа метрик в разработке, автоматизация сборки, проверки и доставки приложения приводят к тому, что процессы разработки становятся более прозрачным и управляемыми. В результате к созданию ПО начинают предъявляться требования нового уровня. Одним из таких требований оказывается желание разнести во времени моменты публикации приложения и включения новой функциональности, что и реализуется переключателями. Возможности отрасли уже созрели для удовлетворения этой потребности в промышленных масштабах.
Немного подробнее
В этой заметке есть хорошая схема, иллюстрирующая работу переключателей; предлагаю с ней ознакомиться.
Начнем рассмотрение схемы с кода. Пусть в нашем примере новая функциональность — проверка правильности заполнения документа. Сделаем так, чтобы документ проверялся, только если эта функциональность включена. Сделаем точку переключения:
В данном случае feature — это ссылка на инфраструктуру, помогающую нашему приложению общаться с маршрутизатором и реестром функциональности. С помощью данной инфраструктуры мы выясняем, нужно ли проверять документ, и если да, то проверяем его.
Маршрутизатор пользуется доступной ему информацией: названием функциональности, которое мы передали в качестве аргумента, и тем, что можно извлечь из известных ему статических классов, — чтобы определить, должна ли в данном случае работать запрошенная функциональность. Маршрутизатор выясняет, как сконфигурированы переключатели в реестре. Если реестр недоступен, то нужно либо воспользоваться ранее закэшированными данными, либо прибегнуть к еще какой-нибудь стратегии на этот случай. Также можно представить маршрутизатор, который явно через аргументы метода принимает дополнительную информацию (контекст), помогающую ему решить, включать ли в данный момент функциональность или нет.
Ответственные сотрудники конфигурируют переключатели выбранным способом. В самом приятном варианте они заходят на сайт, представляющий реестр переключателей, и мышкой щелкают по выбранным переключателям.
Итак, в смысле артефактов система переключателей состоит из двух частей. С одной стороны, это инфраструктура для программиста, позволяющая выяснить, должна ли функциональность работать в данном случае, и направлять исполнение по соответствующей ветке кода. С другой стороны, это механизм, позволяющий ответственному сотруднику выбирать, какую функциональность включить, а какую — выключить. В вырожденных случаях (когда реестр зашивается в код, см. ниже) оба артефакта могут совпадать, а программист может управлять включением и выключением функциональности.
Возможные требования к системе переключателей
Как видно, система переключателей может быть довольно сложной штукой. Перечислим основные требования, которые могут предъявляться к такой системе.
Технологическое дерево
Обобщим рассмотренные сведения о переключателях функциональности, прибегнув к метафоре технологического дерева из видеоигр. Представим переключатели как технологию, позволяющую компании выкатывать новую функциональность, не привязываясь к моментам сборки и развертывания приложения. У этой технологии есть известная стоимость (расходы на поддержку жизненных циклов переключателей и реестра) и предпосылки внедрения: гибкая методология разработки плюс непрерывная интеграция. Конечно, непрерывная интеграция — это не обязательная предпосылка, но она делает переключатели существенно более эффективными и позволяет обеспечить непрерывную доставку приложения. Кроме того, «исследование» переключателей «открывает» другие технологии — A/B-тестирование и канареечные выпуски. О них будет сказано далее.
Где может находиться реестр функциональности
Рассмотрим несколько вариантов размещения реестра функциональности, расположив их по возрастанию сложности реализации.
Рекомендации
Касательно использования переключателей можно дать следующие рекомендации общего характера.
Точка переключения и логика не обязаны быть вместе. В простейшем примере после условного оператора, в котором мы опрашиваем состояние конкретного переключателя, сразу идет код, реализующий включенную функциональность. Это не совсем удобно, потому что добавляет в логику избыточные зависимости: знание о самой инфраструктуре переключателей и о названии конкретной функциональности из реестра. На практике это приводит к усложнению тестирования и процесса удаления переключателя, когда он станет ненужным.
Ставить точку переключения повыше. Развитие предыдущего пункта. Точки, в которых происходит обращение к инфраструктуре переключателей, следует до последней возможности исключать из логики предметной области, то есть «выпихивать» их поближе к месту приема запроса. Таким образом мы уменьшаем зависимость отдельных модулей от переключателей, упрощаем процессы их поддержки и тестирования.
Использовать стратегии вместо условных операторов. Если переключатель собирается жить долго, то условный оператор можно улучшить до стратегии и явно выделить переключаемую логику во что-то отдельно сопровождаемое и тестируемое.
Не группировать переключатели. Не стоит образовывать зависимости между переключателями, группировать их и собирать в иерархии. Так будет легче поддерживать и код с новой функциональностью, и жизненный цикл самих переключателей.
Консолидировать точки переключения для одной функциональности. Может оказаться, что поведение сразу нескольких программных блоков зависит от одного и того же переключателя. Если разработка плохо согласована, точки переключения могут дублироваться в разных местах, а это приводит к удорожанию тестирования и поддержки. Если дисциплинированно стараться «выталкивать» точки переключения ко входу в приложение, то данная рекомендация — не разбрасывать точки по всей системе — обычно выполняется автоматически.
Основные категории переключателей
Рассмотрим классификацию переключателей, приведенную в этой статье. Она основана на том, сколько времени «живет» переключатель и как часто меняется его состояние. Отнесение переключателя к конкретному классу помогает определиться с тем, как использовать переключатель в коде и как хранить состояние переключателя.
Переключатели для выпуска
Это основной вид переключателей. Они позволяют сконцентрировать разработку в одной главной ветке, которая, к тому же, регулярно «выкатывается» в промышленную эксплуатацию. Вместо того чтобы вести разработку в отдельной ветке и вливать ее в главную ветку для выпуска нужной версии, мы внедряем в код точку переключения, которая скрывает от пользователей еще не готовую функциональность. По мере готовности переключатели запускают новую функциональность.
Такие переключатели живут несколько дней или недель — пока идет разработка и внедрение новой функциональности. Когда функциональность опробована и признана подходящей, переключатель и точку переключения в коде можно упразднить. Состояние переключателя обычно меняется или в момент выпуска новой версии, или при изменении конфигурации приложения. Допустимо хранить такой переключатель в конфигурационном файле. Существует большая вероятность, что точка переключения для новой функциональности будет единственной; имеет смысл не закапываться и оформить ее в виде обычного условного оператора.
Переключатели для проведения экспериментов
Для обкатывания новой функциональности применяются переключатели, живущие от нескольких дней до нескольких месяцев. Во время эксперимента можно следить за тем, как пользователи воспринимают изменения и как изменяется их поведение. Желательно, чтобы состояние переключателя могло меняться очень динамично, с каждым запросом. Сюда скорее подходит какое-то централизованное хранилище, типа БД или сетевой службы. Если эксперимент умещается в обозримое число выпусков, то точку переключения также можно оформить в виде условного оператора.
Технические переключатели помогают управлять инфраструктурными частями приложения, влияющими на его работу в целом. Они могу пригодиться, когда мы выкатываем обновление, влияние которого на производительность трудно оценить. В таком случае хорошо бы иметь «рубильник», мгновенно отключающий новую функциональность, если окажется, что ее использование приводит к катастрофическим последствиям.
Скорее всего, такие переключатели будут жить несколько недель или дольше, а менять состояние будут при изменении конфигурации приложения либо чаще. Критичность функции, которую реализуют эти переключатели, наводит на мысль, что для них надо использовать сетевую службу или хотя бы БД. Нужно начинать следить, чтобы в коде точки переключения для одной и той же функциональности не оказались разбросаны по разным местам.
Переключатели для разграничения доступа
Еще одна очевидная возможность пользоваться переключателями — предоставлять доступ к новой функциональности только некоторым пользователям. Это может понадобиться как для канареечного выпуска (когда новая функциональность постепенно охватывает все больше и больше пользователей), так и для создания закрытых разделов, куда имеют доступ только привилегированные пользователи.
Похоже, что такие переключатели живут довольно долго (возможно, столько же, сколько и само приложение) и могут менять состояние при каждом новом запросе. Здесь также подойдет сетевая служба для хранения переключателей. Рекомендуется пользоваться каким-то централизованным механизмом выбора между старой и новой функциональностью и не разбрасывать условные операторы по всему коду.
Интересные вещи, которые становятся проще с переключателями
Внедрение переключателей функциональности не только имеет явные преимущества, ради которых обычно все и затевается (разнесение во времени моментов публикации приложения и включения новой функциональности, уменьшение количества веток в СКВ), но также может упростить некоторые побочные процессы. Перечислим их и далее рассмотрим некоторые более подробно.
A/B-тестирование. Сравнение поведения пользователей, пользующихся новой и старой версиями.
Канареечные выпуски. Постепенное увеличение количества пользователей, имеющих доступ к новой функциональности.
Сине-зеленые выпуски. Направление запросов с помощью балансировщика либо на сервер со старой версией, либо на сервер с новой версией.
Плановая экстремальная функциональность. Включение функциональности на некоторый короткий промежуток времени, например во время проведения акции.
Одновременное включение функциональности в нескольких местах. Включение функциональности одновременно и на сайте, и в мобильном приложении. Либо включение функциональности одновременно в разных модулях одного и того же приложения.
Серьезные инфраструктурные изменения. Например, переход к другому способу хранения данных.
Апробирование новых вещей пользователями. Предоставление пользователям возможности включать и выключать новую функциональность, настраивая приложение под себя.
Кратко рассмотрим, что такое A/B-тестирование. При подготовке A/B-тестирования формулируется какое-то измеряемое свойство работы информационной системы или поведения пользователей. Примеры такого свойства: 1) продолжительность конкретного процесса предметной области, 2) относительное количество пользователей, попавших на конкретную страницу, 3) количество ресурсов, которыми пользуется приложение. Кроме того, делается предположение, как значение этого свойства изменится при включении новой функциональности. Будут ли пользователи быстрее получать ответ? Будут ли больше покупать? Будет ли приложение меньше «кушать»?
Затем, во время A/B-тестирования, для одной группы новая функциональность включается, а для другой — остается выключенной. Выдвинутое при подготовке предположение проверяется, и на основании результатов делается вывод о том, дает ли новая функциональность что-то хорошее и не приводит ли она к чему-то плохому. Иногда пользователей разделяют на три группы, в двух из которых функциональность остается старой. Если результаты двух контрольных групп сильно отличаются, значит, и весь тест содержит какую-то ошибку, делающую недостоверными выводы на основе этого теста.
Переключатели функциональности позволяют легко разделять пользователей на группы и управлять ими. Для каждой группы можно включить и выключить новую функциональность, не дожидаясь очередного выпуска приложения. Это сокращает время, которое требуется для проверки предположений и для прохождения всего цикла A/B-тестирования. Многие компании стремятся наладить проверку сразу нескольких предположений в неделю.
Подробнее об этом методе можно узнать из этой заметки, здесь и здесь на «Хабре», и еще точно стоит посмотреть доклад «Feature Toggles, или Как выкатывать фичи без релиза», где раскрываются некоторые интересные тонкости A/B-тестирования с переключателями функциональности.
Канареечные и сине-зеленые выпуски
При чем тут канарейки? Канарейки использовались в горнодобывающей промышленности: шахтеры брали канареек в клетке вместе с собой, когда опускались в шахту, где подозревалась высокая концентрация взрывоопасных газов. Канарейки очень любят чистый воздух и намного раньше людей начинают ощущать в нем вредные и опасные примеси. Если канарейка прекращает петь, отключается или погибает, то людям нужно срочно эвакуироваться, пока не рвануло. Вот здесь можно почитать об этом более подробно (на английском).
Отсюда, как я понимаю, и произошло выражение «свидетельство канарейки». Если вы живете в государстве, проводящем репрессивную внутреннюю политику (т. е. в любом), то можете обнаружить однажды, что вам пришло распоряжение не только передать личные данные ваших пользователей уполномоченным ведомствам, но еще и не сообщать никому ни о том, что вы их сдали, ни о том, что вы получили такое распоряжение. Выкрутиться, конечно, не получится, но в некоторых случаях можно регулярно отправлять своим пользователям сообщения такого вида: «В прошедшем месяце мы не получали распоряжений о раскрытии ваших личных данных». Вот так вы щебечете-щебечете, как канарейка, а когда получаете распоряжение о предоставлении личных данных, замолкаете. Тем самым вы и исполняете требование властей, и даете повод вашим пользователям насторожиться.
А еще есть канареечные выпуски. Здесь метафора работает так: когда какой-то маленькой части пользователей становится плохо, мы срочно «эвакуируемся» — сворачиваем новую функциональность, из-за которой пользователям поплохело, и не даем ей охватить всех пользователей (не даем «рвануть»). Для этого надо иметь возможность распространять новую функциональность на различные группы. Здесь можно обойтись и без переключателей. Например, у нас есть балансировщик и два узла, куда он перенаправляет запросы. На одном узле у нас развернута стабильная версия, а на втором — экспериментальная версия, содержащая новую функциональность. По умолчанию все запросы отправляются на узел со стабильной версией, и с помощью балансировщика мы начинаем некоторые запросы отправлять на узел с экспериментальной версией.
Но с помощью переключателя можно добиться большей гибкости в том, как новая функциональность распространяется на пользователей. В переключателе можно объединить разные параметры принимаемых запросов и предоставить ответственным сотрудникам удобный графический интерфейс для управления канареечным выпуском. В целом процесс остается таким же: мы включаем новую функциональность для небольшой группы пользователей, например для 1 %. После этого мы наблюдаем за состоянием приложения, за тем, как ведут себя пользователи, работающие с новой функциональностью, и делаем прогноз о том, что будет, когда мы распространим ее на большее число пользователей. Постепенно охватывая новой функциональностью все больше и больше пользователей, мы можем проверять и корректировать наши гипотезы. Если мы заметим негативные тенденции, то новую функциональность можно будет легко отключить.
Во время сине-зеленого выпуска используются два сервера, условно называемые синим и зеленым. Будем считать, что до выпуска балансировщик отправляет все запросы на зеленый сервер. Во время выпуска новая версия приложения развертывается на синем сервере, куда балансировщик также начинает отправлять запросы. Если оказывается, что новая версия приложения содержит ошибки, то мы переключаемся обратно на зеленый сервер.
Базовый вариант сине-зеленого выпуска предполагает, что пользователи либо работают со всей новой функциональностью, включенной в новую версию, либо не работают ни с какой. А с использованием переключателей появляется возможность во время выпуска направить запросы на синий сервер с новой версией, для которого переключатели всей новой функциональности выключены. После этого можно постепенно включать новую функциональность по частям.
Можно видеть, что переключатели функциональности позволяют объединить преимущества канареечных и сине-зеленых выпусков. Обычно во время сине-зеленого выпуска имеется два четко разделенных узла со старой и новой версией приложения, и с помощью балансировщика мы перенаправляем сразу все запросы либо на один узел, либо на другой. А с переключателями мы можем перенаправить запросы на узел с новой версией, но с выключенной новой функциональностью, а затем постепенно включать ее, как во время канареечного выпуска.
Чуть-чуть подробнее о канареечных выпусках — в соответствующей заметке на сайте Фаулера или на «Хабре», например здесь. О сине-зеленых выпусках — в обзорной статье. А об использовании переключателей функциональности в сине-зеленых выпусках можно почитать здесь.
Изменение способа хранения данных
Еще давно, при изучении таких приемов в программировании, как абстракция и разработка от интерфейсов, я часто встречал следующую рекомендацию: старайтесь, чтобы ваша программа не привязывалась к конкретному способу хранения данных, например, к определенной БД, потому что в будущем вам может понадобиться изменить способ хранения. Я это на ус намотал и делал как велено. С тех пор, однако, причины, по которым я разделяю логику предметной области и способ хранения, изменились, а к возможности смены БД в коммерческом продукте я, наоборот, начал относиться скептически.
И вот при подготовке данного материала я узнал о ребятах, которые уверяют, что множество компаний практикует смену БД в промышленно эксплуатируемых продуктах. Кроме того, поменять БД якобы можно совсем безболезненно, если пользоваться переключателями функциональности. Понятно, что упомянутая статья написана людьми заинтересованными (сайт поддерживается производителем коммерческого инструмента для управления переключателями), но рассмотреть предложенную ими стратегию перехода на другую БД не помешает.
Вкратце описать стратегию можно так. Процесс начинается с того момента, когда наше приложение работает с одной (старой) БД. Пользуясь переключателями функциональности, мы последовательно заставляем наше приложение сначала писать данные в новую БД, а потом — читать данные из новой БД. При этом взаимодействие со старой БД сохраняется: мы и пишем, и читаем из обеих БД!
Если с записью все более-менее понятно, то про чтение надо пояснить. Когда приложению нужны данные, оно читает их из обеих БД. Эти две точки чтения всегда находятся рядом таким образом, чтобы после чтения можно было сравнить полученные данные и проверить их согласованность. После стабилизации приложения (когда обе БД начинают стабильно возвращать одинаковые данные) приложение отключается от старой БД, а переключатели удаляются.
В примере рассматривается переход с MongoDB на DynamoDB. При подготовке к переходу создается вся необходимая инфраструктура для работы с DynamoDB: подключаются драйверы БД и создаются репозитории (в приложении) по аналогии с репозиториями MongoDB. Создаются четыре переключателя — по два для каждой БД, один из которых показывает, нужно ли записывать в эту БД, а второй — нужно ли читать из этой БД. С помощью этих переключателей далее и осуществляется переключение на новую БД (DynamoDB).
Можно рассмотреть и вариант, когда часть данных должна храниться в MongoDB, а часть — в DynamoDB. Тогда группа из четырех переключателей заводится для каждого фрагмента данных, который предполагается изолированно переводить в DynamoDB (или оставлять в MongoDB). Далее будем считать, что мы переносим в DynamoDB все данные сразу и поэтому пользуемся ровно четырьмя переключателями.
На первом этапе мы дублируем в DynamoDB все, что записывается в MongoDB. При этом читаем мы по-прежнему из MongoDB. Помним, что переключатели позволяют нам выбирать любые комбинации чтения и записи. Кроме того, у нас есть возможность сделать не бинарный переключатель («включено» и «выключено»), а более гибкий. Так что по-хорошему мы начинаем дублировать запись в DynamoDB только для небольшого числа пользователей. Постепенно увеличивая это число, мы наблюдаем, как себя ведут приложение и БД. Если что — останавливаемся и работаем над ошибками.
На втором этапе мы начинаем читать и из MongoDB, и из DynamoDB. В месте, где требуются прочитанные объекты, мы сравниваем данные, полученные из разных БД, и, если они отличаются, кидаем исключение. Либо можно выйти из положения как-то более изящно, например все таки отдать наружу объект, загруженный из MongoDB, но зарегистрировать ошибку чтения в журнале, чтобы потом с ней разобраться. В конце концов мы должны добиться того, чтобы объекты, получаемые из разных БД, были полностью идентичными. При расследовании ошибок и отладке нам опять помогает постепенное увеличение числа пользователей, охваченных нововведением.
На заключительном этапе мы должны как писать все данные в обе БД, так и читать данные из обеих БД. Чтение уже должно быть отлажено и настроено так, чтобы программа работала только с объектами, полученными из DynamoDB. В этот момент у нас появляется возможность отключить как запись в MongoDB, так и чтение из нее.
Вот и все. Насколько я понимаю, здесь, как не относящийся к теме, обойден вопрос переноса в DynamoDB данных, хранившихся в MongoDB до того, как мы начали писать в DynamoDB на 100 %. Тем не менее описанный прием кажется довольно интересным, особенно как пример эффективного использования переключателей при серьезных архитектурных изменениях.
Одновременное включение функциональности на разных платформах
В уже упомянутом докладе «Feature Toggles, или Как выкатывать фичи без релиза» рассказывалось о требовании включить новую функциональность одновременно (минута в минуту!) и на сайте, и в мобильном приложении. А потом еще может потребоваться выключить ее таким же образом.
Выполнить такое требование непросто, поскольку доставки новых версий для разных платформ очень трудно синхронизировать. Если серверы с сайтом находятся под вашем контролем, то здесь еще можно что-то подгадать (и надеяться, что в этот раз доставка отработает как часы), то магазин мобильных приложений может менять политику выпуска обновлений, как ему заблагорассудится. В любом случае обновление приложения — долгий процесс, который включает проверку публикуемого приложения самим магазином. Кроме того, не стоит надеяться, что мобильное приложение будет само регулярно запрашивать обновления у своего API и устанавливать их «внутри» себя. Эта лавочка, как я понял, тоже находится под тщательным надзором владельца платформы — с исполнением произвольного кода уж точно будут проблемы.
А вот переключатели помогают выполнить требование одновременного включения функциональности в условиях, когда вы не можете полностью контролировать доставку приложения. Очевидно, доставка все же должна гарантированно случиться до момента ожидаемого включения. Такой метод наверняка пригодится в периоды проведения временных акций, например «Черной пятницы».
Похожая ситуация и с несколькими модулями одной системы. Если они публикуются по отдельности и при этом участвуют в поддержке одного процесса предметной области, то переключатели позволяют внести согласованные изменения в этот процесс на стороне различных модулей.
Комбайны
Похоже, это самый раскрученный и «зубодробительный» продукт в области переключателей функциональности. Складывается ощущение, что в этом продукте уместили почти все, что только может прийти в голову, когда говорят о переключателях. Это касается и возможностей самой платформы, и разнообразия доступных клиентов, и видов интеграции с разными инструментами типа Jira и Visual Studio Code. Все документировано очень подробно и с примерами. Инструмент, конечно, платный, но в течение пробного 30-дневного периода им можно пользоваться бесплатно.
Компания Catamorphic Co., производящая этот продукт, также опекает специальный сайт-справочник о переключателях функциональности.
Клиентская библиотека предлагает интересные возможности по интгерации с ASP.NET Core, например дополнительные фильтры на действия контроллеров и условная визуализация представления, зависящая от состояния переключателей.
В комментариях к данной статье предлагают ознакомиться с полезным циклом заметок, посвящённым Microsoft.FeatureManagement.
Сайт выглядит мило, но при попытке получить конкретную информацию начинаются проблемы. Например, указано, что продукт имеет много интересных возможностей для аудита переключателей, наблюдения за использованием функциональности и проведения экспериментов. Но при этом производители не раскрывают ценовую политику (ясно только, что есть 14-дневная бесплатная пробная версия) и ведут довольно сырую документацию своего REST API. Документация к клиентским библиотекам, впрочем, в порядке. Система поддерживает хранение переключателей в конфигурационных файлах.
В целом Optimizely — это какая-то крутая платформа для сбора аналитики и проведения экспериментов. У системы есть бесплатная часть Rollouts, предоставляющая базовые возможности переключателей. Написано, что, кроме поддержки таргетирования («раскатывания» функциональности на определенные группы пользователей), эта бесплатная часть поддерживает бесконечное количество переключателей и проектов. Кроме того, пользоваться этой системой может сколько угодно сотрудников. Стоит отметить, что стоимость многих других продуктов определяется именно этими количественными характеристиками. Сколько будет стоить переход на полностью функциональную платформу — секрет.
Эта платформа выглядит довольно простой. Она не имеет каких-то особенных функций вроде сбора аналитики — только основные возможности переключателей. При размещении платформы на своих собственных серверах ею можно пользоваться бесплатно. Также см. рекомендацию в комментариях.
Еще одна платформа, которая стесняется своих цен. Из дополнительных «фишек» предлагает интеграции с немногими другими инструментами разработки и поддержку проведения экспериментов (A/B-тестирования).
Проект с открытым исходным кодом, включающий сервер с сайтом для управления переключателями и клиент. Для запуска сервера требуется SQL Server. Выглядит довольно зрелым.
Серверы
Довольно зрелый открытый проект, который предполагает размещение системы на серверах компании. Включает простенький сайт для управления переключателями. Есть встроенные простейшие средства для учета использования функциональности. Установка довольно простая; требуется PostgreSQL.
GitLab построил свою систему переключателей поверх Unleash, поэтому для взаимодействия с GitLab используются те же самые клиентские библиотеки, что и для Unleash. От самого Unleash отличается тем, что нужно меньше копаться с установкой (если не считать установку самого GitLab), но при этом нужно платить: переключатели функциональности доступны начиная с планов GitLab Premium (если GitLab запускается на ваших собственных серверах) и GitLab Silver (если GitLab запускается на серверах поставщика).
Этот открытый проект представляет собой службу с API (немного документирован), через который можно управлять переключателями. Видимо, графический интерфейс отсутствует. Написан на Go; использует встроенные БД и сетевой сервер, поэтому настройка, судя по инструкции, тривиальна. Предоставляет зачаточные возможности для таргетирования. Последняя правка в репозитории: 20 февраля 2019.
Еще один открытый проект на Go. Устанавливается из Docker. Есть графический интерфейс, а также клиенты для Ruby, Go, JavaScript, Python. Предлагает встроенные простейшие средства для учета использования функциональности и проведения экспериментов. Каждый переключатель можно гибко настроить и снабдить собственной конфигурацией.
Клиентские библиотеки
Самый интересный, хорошо документированный и функциональный проект своей группы. Встроенный механизм хранения — либо конфигурационный файл, либо EF Core. Немного интегрируется с ASP.NET Core (как Microsoft.FeatureManagement); в документации сказано, что с помощью Azure можно упростить конфигурирование переключателей.
Может запрашивать состояние переключателя и из конфигурационного файла, и удаленно (настраивается с помощью классов пространства FeatureSwitch.Strategies ). В комплекте есть каркас простенького сайта, позволяющего управлять переключателями. Непонятно, есть ли возможность сделать более сложный переключатель, чем «включено/выключено».
Простейшая библиотека для работы с переключателями, которые хранит в текстовом файле. Видимо, поддерживает только переключатели вида «включено/выключено».
Клиентская библиотека для ASP.NET Core. Помимо того, что позволяет использовать переключатели функциональности, поднимает вместе с основным сайтом проекта дополнительную страничку, на которой можно управлять переключателями. Встроенный механизм хранения конфигурации — SQL Server.
Содержимое колонки «Плюшки» расшифровывается примерно следующим образом.
Аудит. Инструмент ведет учет, кто, когда и как изменил состояние переключателя.
Таргетирование. Инструмент предоставляет возможность ограничить группу пользователей, которым доступна функциональность, по идентификаторам, географическому положению или иным характеристикам.
Поддержка экспериментов. Инструмент собирает статистику использования функциональности и некоторых параметров приложения, упрощая проведение A/B-тестирования.
Аналитика. Инструмент представляет собранную по процессам предметной области статистику в удобном для анализа виде.
Интеграции. Для инструмента налажены интеграции с другими популярными средствами разработки и управления проектами.
Заключение
Похоже, что во многих компаниях уже стало обычной практикой использование переключателей для разнесения во времени моментов выпуска версии и включения новой функциональности. Дополнительно переключатели помогают снизить градус безумия во время слияния веток в системе контроля версий. Кроме того, они открывают дорогу к таким популярным методикам, как канареечные выпуски и A/B-тестирование.
Для работы с переключателями создано так много программного обеспечения, как платного, так и бесплатного, что любая компания может выбрать инструмент себе по вкусу.
В качестве итогов перечислю особенности переключателей функциональности и волюнтаристски (как водится) разделю их на преимущества и недостатки.