Как убедить разработчиков начать использовать переключатели флагов функций?

Предполагая, что переключатели флагов функций являются хорошей идеей, они должны быть реализованы в коде, который пишут разработчики. Например, Etsy клянется ими как основной частью их культуры .

Каков хороший способ убедить (и заставить) разработчиков начать использовать переключатели флагов функций?

Более подробная информация о переключателях флагов функций объяснена в Q: Как использовать переключатели флагов функций , Q: Что такое переключатели флагов функций и очень подробно в статье Пита Ходжсона на эту тему в блоге Мартина Фаулера .

Переключатели функций являются обычной практикой в ​​высокоскоростной разработке, потому что они отсоединяют разработку от выпуска. Команды разработчиков могут «мягко выпустить» новую функцию для производства в отключенном состоянии. Это позволяет функции быть выпущенной в любое время. Если функция зависит от другой работы или подготовки, ей не нужно ждать выхода основного выпуска для запуска.

Что касается «убеждения» разработчиков в их использовании, то это упражнение в обосновании свободы, которую оно предлагает. Мой опыт показывает, что это не сложно продать разработчикам. Это управление, которое склонно неохотно пробовать новые вещи. Попробуй это:

• Найти функцию переключения рамки. Управление / бизнес могут быть более склонны к тому, чтобы попробовать что-то, поддерживаемое общей системой
• Начните с малого. Представьте систему переключения на пробной основе для функции, которая продемонстрирует ее полезность.
• Продемонстрировать способность переключателя проводить A / B-тестирование. Включите переключатель для подмножества вашей веб-фермы, затем соберите показатели поведения. Крошечные различия в макете страницы, как было продемонстрировано, имеют огромное влияние на доход для розничных приложений (например, Ebay, Amazon)

В идеальном мире я думаю, что вы выкатите новую сборку и удивите! НИЧЕГО не меняется. Это потому, что все ваши новые функции находятся за выключателями, которые выключаются.

После развертывания вы проверяете, что ваша развернутая служба по-прежнему работает, телефоны больше не звонят (если только звонки не являются вашей целью), и т. Д. Как только вы вернетесь к известной стабильной работе, вы начнете включать и проверять ваши недавно развернутые функции.

А теперь ответ на ваш вопрос: как бы вы хотели работать в команде, где вызов практически не вызывает затруднений, и наши пользователи любят нас, потому что наши сайты и сервисы стабильно работают?

Это команда, над которой я хочу работать.

Вы можете перестать читать здесь, если хотите.

Кажется, что все, что стоит за переключателем функций, может повсеместно привести к появлению спагетти-кода. Если вы используете IoC и можете выбирать между vNow / vNext / vPrevious, то все сводится к поддержке вашей конфигурации. Да, больше проверок, да больше классов (componentV1, componentV2, componentV3 и т. Д.), Но у вас на самом деле более стабильная система? Как? vNext является шатким? Вернитесь к vNow с вашей контрольной башней. Прошла неделя и у vNow есть тонкий баг? То же самое - вернуться к vPrevious так же легко.

Нет хлопот, нет забот, нет потерянного сна, нет стресса.

Это не несбыточная мечта. Я раньше работал там. Хотел бы я продать это моей нынешней команде.

Успешная высокоскоростная среда разработки обычно опирается на довольно строгую автоматизированную систему, включающую проверки качества с обнаружением и отклонением ошибочных изменений, вызывающих регрессию.

Функциональные переключатели предоставляют возможность фиксировать даже незавершенные, незавершенные изменения без отклонения из-за регрессии в ветви интеграции. Что является очень хорошим стимулом для введения функции, переключающей очень рано в жизни функции.

Одним из недостатков отклонения от истинной CI и разработки движущихся функций в ветвях функций является отсутствие такого стимула. Добавление функции переключается позже, когда объединение ветви функции с веткой интеграции обычно более сложно, как любая поздняя интеграция.

Разработчики (и обычно менеджеры по разработке) обычно ищут два результата, связанных с платформой: простота управления и скорость развертывания. Вы хотите отправить код быстрее и проще.

Предоставить доказательства того, что подход работает; попробуйте создать небольшой POC, используя функциональные флаги по сравнению со старым способом. Тематические исследования имеют меньшее значение для тактических людей (разработчиков \ инженеров), чем для стратегических людей (менеджеры среднего звена \ проектировщики продуктов).

Обоснование наличия переключателей функций - это не то, что разработчики должны решать. Это то, о чем заботятся владельцы продукта. Разработчики делают это изменение максимально устойчивым и безопасным. Я критикую этот самый вопрос.