Фича тоглинг что это
Что такое 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-ов и их ревизию, чтобы удалять неиспользуемые и, как следствие, очищать проект от “мёртвого” кода.
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, что думаете. Буду признателен за фидбек.
Не пишем код целый месяц и нам нормально
Комментарии 10
iOS приложения сейчас проходят ревью от нескольких минут до нескольких часов. А вот Android.
Для нас это тоже было неожиданностью. Дивный новый мир
Выглядит как разница нейминга разных компаний. Тесты писать можно, но лучше сильно не рефакторить, это может так же увеличивать риски как и новая фича.
Почему вы не рассматриваете вариант с feature enabling managment?
Почему не рассматриваем? Мы постоянно этим пользуемся, в статье есть про фича-тоглы.
Бывают изменения, которые нельзя затоглить или это очень сложно/дорого
Можно сломать и в процессе тоглинга, это не спасение от всех бед
Читал пролистывая 🙂 Было бы интересно глобальный фичатогл на все приложение, чтоб откатываться если что.
Но вообще, конечно, мир оффлайн приложений это боль по умолчанию.
У Убера была такая история, когда они все переписывали и буквально зарелизили два приложения. Даже по описанию это очень больно.
Что такое 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, что нарушает стройную идиллию и слегка рушит мозг.
Что если в программе нельзя назначать горячие клавиши?
Значит, это хреновая программа. Найди хорошую. Либо напиши разработчикам, чтобы вынесли нужную функцию в основное меню. Часто независимые разработчики слушают пользователей. Если ты программист — напиши хорошую самостоятельно. Хватит это терпеть!