Что такое 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 или как избавиться от мучительных мёржей и долгоживущих веток?
Проблема
Представьте, что циклы разработки вашей команды длятся по две недели, а реализация новой фичи потребует от команды 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 или как избавиться от мучительных мёржей и долгоживущих веток?
Проблема
Представьте, что циклы разработки вашей команды длятся по две недели, а реализация новой фичи потребует от команды 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-ов и их ревизию, чтобы удалять неиспользуемые и, как следствие, очищать проект от “мёртвого” кода.
Доступный toggle
Приглашаем всех желающих на открытый урок «CSS Reset — ненужный артефакт или спасательный круг». На этом вебинаре рассмотрим, зачем нам CSS Reset, что такое рендеринг и как браузер рендерит страницу.
Toggles (или их еще называют «тумблеры»/»переключатели») широко используются в современных интерфейсах. Они, как правило, относительно просты, и их можно рассматривать как простые флажки (checkbox). Тем не менее, их часто делают недоступными тем или иным способом.
В этой статье я покажу небольшую имплементацию доступного toggle на HTML + CSS, которую вы можете применить в своих проектах и доработать по своему усмотрению.
The toggle и дескриптор handle
Разметка
Стоит отметить, что это не единственный способ разметки такого компонента интерфейса. Например, вместо него можно использовать 2 radio inputs. Sara Soueidan более подробно рассказывает о проектировании и создании toggle.
Теперь нам понадобится немного больше. Чтобы не передавать статус флажка, полагаясь только на цвет (Критерий успеха WCAG 1.4.1 «Использование цвета»), мы собираемся использовать пару иконок.
Мы будем использовать небольшой контейнер между вводом данных и текстовой меткой, который будет содержать 2 иконки: галочку и крестик (взяты из иконок Material UI). Затем мы создадим toggle handle с псевдоэлементом, который будет охватывать одну из иконок за раз.
Следует отметить несколько моментов, связанных с нашей разметкой:
Мы используем aria-hidden=»true» для наших SVG, потому что они не должны обнаруживаться вспомогательными технологиями, так как являются сугубо декоративными.
Мы также используем focusable=»false» для наших SVG, чтобы избежать проблем с Internet Explorer, где SVG по умолчанию фокусируются.
Стили
Прежде чем мы углубимся в стилизацию, я хотел бы уточнить терминологию, чтобы было легче следить за развитием событий:
Контейнер
Давайте начнем с базовых стилей для нашего контейнера.
Toggle и handle
Переход здесь осуществляется таким образом, что handle плавно скользит из одной стороны в другую. Это может немного отвлекать или настораживать некоторых людей, поэтому рекомендуется отключить этот переход, когда включена функция reduced-motion (уменьшение движения). Это можно сделать с помощью следующего фрагмента:
Стили для фокуса
Мы вставили наш контейнер toggle после самого ввода, чтобы использовать комбинатор смежных сиблингов ( + )для стилизации toggle в зависимости от состояния ввода (проверен, сфокусирован, отключен. ).
Я заметил одну интересную вещь: при нажатии на родной флажок или его метку контур фокуса не появляется. Это происходит только при фокусировке флажка с помощью клавиатуры. Мы можем имитировать это поведение, удалив стили, которые мы только что применили, когда селектор :focus-visible не подходит.
Проверенное состояние
Затем нам нужно разобраться с проверенным состоянием. В этом случае мы хотим сделать две вещи: обновить цвет фона toggle с красного на зеленый и сдвинуть handle вправо, чтобы он закрыл крестик и показал галочку (100% собственной ширины).
Adrian Roselli справедливо заметил, что эта схема не учитывает возможное «смешанное» (или «неопределенное» состояние). Это справедливо для простоты, поскольку большинство флажков/тумблеров не нуждаются в таком состоянии, но его следует учитывать, когда это необходимо.
Отключенное состояние
Наконец, мы можем добавить несколько пользовательских стилей, чтобы сделать отключенный toggle более явным.
Поддержка право-лево
Иконки
Вариант кнопки
Adrian Roselli в своем материале о toggles предлагает дерево решений для выбора между флажком и кнопкой.
Затем нам нужно убедиться, что не похожа на саму кнопку. Для этого мы сбросим стили кнопки по умолчанию, включая контур фокуса, поскольку он применяется при toggle (переключении).
Затем нам нужно дополнить все наши селекторы, связанные с вводом, вариацией для выбора варианта кнопки.
Вот и все! Таким образом, мы можем использовать либо разметку флажка, либо разметку кнопки, в зависимости от того, что больше подходит для данной ситуации, и иметь одинаковые стили в обоих случаях. Очень удобно!
Заключение
Как видите, ничего особо сложного в этом нет, но все же есть над чем подумать. Вот чего мы добились:
Мы используем реальный элемент формы флажка, который мы стилизуем под toggle.
Он передает свой статус с помощью иконографии и цвета.
Он не оставляет артефактов, когда CSS недоступен.
Он имеет собственные стили по фокусу и может быть настроен.
У него есть отключенное состояние.
При необходимости он имеет поддержку право-лево.
Он должен быть относительно легко адаптирован к темному режиму при наличии некоторых глобальных пользовательских свойств.
Здорово! Не стесняйтесь играть с кодом на CodePen, и я надеюсь, что это поможет вам сделать ваши toggles доступными. А также, я рекомендую прочитать эти статьи, чтобы продвинуться дальше:
Toggle buttons от Heydon Pickering
Dion упоминает, что toggle может выглядеть наоборот, и это мнение поддерживает Rawrmonstar, а Mikael Kundert упоминает, что использование флажков обычно проще.
Dynamic Delivery в многомодульных проектах (часть 1)
Привет! Меня зовут Юрий Влад, я Android-разработчик в компании Badoo и занимаюсь внедрением Dynamic Features в наши проекты.
Dynamic Delivery — технология, позволяющая устанавливать и удалять части приложения прямо во время работы для того, чтобы уменьшить место, занимаемое приложением. Если какие-то функции не используются, то зачем пользователю иметь их на устройстве?
В первой части статьи я подробнее расскажу о Dynamic Delivery и его API: как загружать и удалять модули. Во второй части — разберу на примере, как я использовал Dynamic Delivery в нашем приложении и получил экономию на размере приложения в полмегабайта.
Модули для Dynamic Delivery
К функциям, которые не нужны пользователю постоянно и которые могут быть удалены, можно отнести:
Такие функции можно легко вынести в отдельные загружаемые модули, чтобы уменьшить место, занимаемое приложением. Если такой модуль устанавливается не во время установки приложения, то отображаемый вес приложения в Google Play будет уменьшен на вес этого модуля. Меньше размер приложения — больше конверсия установок. Также важно удалять неиспользуемые модули, чтобы ваше приложение занимало меньше места. Когда место на устройстве заканчивается, Google Play предлагает удалить часть приложений, сортируя их в том числе по объёму занимаемого места. И очень не хочется оказаться в самом начале этого списка.
Модули с перечисленными выше функциями могут содержать в себе код и любые типы ресурсов. После установки классы будут загружены в ClassLoader и их можно будет использовать. К ресурсам можно будет обращаться из установленного модуля. Но есть одно но.
Dynamic Feature Module
С точки зрения структуры модулей в Gradle это выглядит так:
Модули в первом ряду ( :about и другие) — Dynamic Feature Modules. Они зависят от основного модуля приложения и могут легко использовать его код и ресурсы. Во втором ряду — модуль приложения, а в третьем — его зависимости.
Кажется, что такое требование использовать рефлексию сводит на нет все преимущества технологии, но я покажу, как при нашем многомодульном подходе можно свести всю рефлексию к двум-трём вызовам.
SplitInstallManager
Схема работы с модулями следующая:
Всё довольно просто и очевидно, за исключением не очень удобного API, который я покажу на примере кода с android.developers.com.
Проверка факта установки модуля
Запрос установки
Прогресс установки
Обновления состояния установки будут приходить в SplitInstallStateUpdatedListener. В него приходят обновления вообще всех сессий, а фильтровать по идентификатору сессии мы их должны сами. В SplitInstallSessionState нам доступны:
Подтверждение от пользователя
Установка
Для поддержки в вашем приложении загрузки классов и ресурсов нужно использовать SplitCompat.
Отложенная установка
Можно попросить Google Play Services установить модуль когда-нибудь потом. Официальная документация описывает это «когда-нибудь потом» как «best-effort when the app is in the background». На практике же модуль загрузится, когда ваше приложение не будет запущено и когда Google Play будет устанавливать обновления вашего или других приложений.
Запросить установку в фоновом режиме очень просто:
При этом вы никак не сможете её отслеживать, так как она банально не будет выполнена, пока ваше приложение запущено.
Несмотря на это ограничение, такой подход вполне может быть полезен. Например, для функций под A/B-тестом. Если вы разместили точку входа в новый экран приложения на видном месте, то пользователь как минимум из любопытства нажмёт на неё. Тогда почему бы не запрашивать установку всех таких модулей в фоновом режиме, чтобы не заставлять пользователя ждать потом?
Соберём всё вместе
Для начала напишем функцию, которая просто проверит, установлен ли модуль moduleName и можно ли использовать требуемый класс className через рефлексию.
В процессе установки нам нужно обрабатывать разные состояния установки модуля. Для этого используем простой sealed class.
Заключение
Технология Dynamic Delivery от Google позволяет загружать и удалять модули прямо во время работы приложения. Это отличный способ сэкономить место на устройстве: как правило, в приложении есть модули, которые используются редко; их можно подгружать в процессе работы приложения по необходимости.
Несмотря на не очень удобный API, всю работу по загрузке модулей вполне возможно скрыть за единым интерфейсом. Запрос на загрузку модулей Dynamic Delivery осуществить легко, но нужно быть внимательным при обработке её десяти различных состояний.
Есть ещё два момента, на которые стоит обратить внимание:
Во второй части статьи я расскажу, как использовал Dynamic Delivery в одном из проектов Badoo.
