Флагом (flag) называется алгоритм, который сообщает программе о том, что выполнено некоторое условие или произошло какое-то событие, так же как настоящий флаг, оставленный астронавтами на Луне, свидетельствует о том, что на лунную поверхность ступала нога человека. Переменной-флагу присваивается значение в начале выполнения программы или во внешнем цикле, а затем ей присваивается другое значение, указывающее на то, что произошло некоторое событие или было выполнено определенное условие.
Например, программа перевода значений температур использует цикл do. while для ввода значений:
printf(«Введите значение температуры
в пределах от 0 до 100: «);
Одна и та же подсказка появляется во всех случаях как при первом вводе, так и в случае ввода ошибочного значения. Возможно, было бы неплохо вывести на экран другое сообщение, указывающее пользователю, что он ввел неправильное значение. Текст программы, в которой именно так и сделано, приведен в Листинге9.4.
Веселый Роджер — пиратский флаг
Листинг 9.4. Программа, в которой используется флаг для отображения альтернативных сообщений.
температуры от 0 до 100: «);
celsius = (5.0 / 9.0) * (temp — 32);
printf(«%d градусов по Фаренгейту
соответствует %6.2f по Цельсиюn», temp, celsius);
printf(«Желаете продолжить ввод?»);
while (repeat == ‘y’ || repeat == ‘Y’);
Переменной с именем flag в начале каждого внешнего цикла присваивается значение ‘n’. В начале каждого повтора внутреннего цикла значение флага проверяется. Если оно равно ‘n’, то программа выводит на экран одно сообщение, при любом другом значении флага на экран выводится второе сообщение.
При первом выполнении цикла флаг имеет значение ‘n’, поэтому на экран выводится первое сообщение. Когда пользователь вводит число, значение переменной меняется на ‘y’. Однако если пользователь ввел неправильное значение, внутренний цикл снова повторяется, но в этом случае условие (flag == ‘n’) не выполнится, так что на экран будет выведено второе сообщение.
Когда пользователь вводит правильное значение температуры, оно преобразуется в значение по шкале Цельсия, и внешний цикл повторяется. При следующем выполнении внешнего цикла флаг переустанавливается заново и пользователю предоставляется новый шанс ввести правильное значение температуры. Обратите внимание, что значение флага переустанавливается при каждом выполнении внешнего цикла, так же как значения счетчика и аккумулятора.
Хотя флаг и может быть определен с любым типом данных, рекомендуется все же выбирать для него тип int или char. Значения, присваиваемые флагу, также целиком определяет автор программы. В нашем примере использовалось значение ‘n’, чтобы отобразить правильный ввод данных, и ‘y’, чтобы отобразить неправильный ввод. Вы можете использовать любые другие значения, какие подскажет ваша фантазия.
Источник: studfile.net
Драка за украинский флаг развернулась в кулуарах саммита в Турции
Флаги для функций
Флаги для функций (feature Flags) это проверенный временем способ, позволяющий контролировать возможности приложения или сервиса самым решительным образом.
Пример
Допустим, у вас есть приложение или сервис, который запускается из командной строки, и у него есть main метод или функция. Вашим флагом функции может быть —withOneClickPurchase , который вы отправляете в качестве аргумента в командную строку. Этот флаг активирует те строчки кода в приложении, которые реализуют функцию покупки в один клик от Amazon.
Без этого аргумента командной строки приложение будет отображать корзину с товарами. Не будем вдаваться в подробности — допустим что разработчики решили сделать именно такую логику приложения. Скорей всего, ‘покупка в один клин’ и ‘корзина с товарами’ на языке бизнеса будет называться точно так же. Все усложняется тем, что эти флаги не обязательно должно быть реализованы как a/b тест или новый/старый функционал — эти функции могут дополнять или подменять друг друга. В нашем примере, может быть нужна возможность сделать —allowUsersToUseShoppingCartInsteadOfOneClick . Как вы видите, флаги могут подменять друг друга.
Флаги это Переключатели
Светило индустрии, Мартин Фаулер, называет эту технику ‘переключатели функций’, и дал им фундаментальное определение (см.ссылки ниже). Тем не менее, в индустрии чаще фигурирует название флаги функций (feature flags), поэтому далее мы будем использовать именно это название.
Атомарность
Может быть и так, что один флаг управляет чем-то большим, например пользовательским интерфейсом какого-то компонента. В примере выше мы определили, что OneClickPurchasing и ShoppingCart это названия компонентов. Возможно, степень атомарности флага должна быть меньше. Допустим, американцы хотят видеть температуру в фаренгейтах, а другие народы в градусах цельсия. У нас может быть флаг —temp=F и —temp=C . Разработчики для прикола могут также добавить температуру в кельвинах —temp=K .
Реализация
Для OneClickPurchasing и ShoppingCart вариантов может быть создана абстракция PurchasingCompleting . Затем на начальном этапе загрузки, который контролируется кодом, флаг —withOneClickPurchase будет влиять на:
if args.contains(«—withOneClickPurchase») purchasingCompleting = new OneClickPurchasing(); >
Внедрение зависимости в Java через настройку:
bootContainer.addComponent(classFromName(config.get(«purchasingCompleting»)));
В общем, есть много путей передать флаг (или любой другой конфиг) в среду выполнения.
Если вы можете, то вам лучше избегать if/else конструкций в коде в том месте, где происходит выбор того, какую часть кода делать активной. Отсюда наш акцент на абстракцию.
Процесс Continuous Integration
Важно, чтобы CI был бдительным при всех ваших ощутимых и ожидаемых изменениях флагов. Это означает, что тесты, которые прогоняются в приложении или сервисе после запуска, должны адаптироваться и проверять то, на что влияют изменения флагов. Это также означает, что с точки зрения процессов CI существует разветвление после unit тестов для каждого ощутимого изменения флага. Грубый пример — запускать весь процесс CI параллельно для каждого ощутимого изменения флагов. Это будет означать, что каждое вливание кода в trunk запускает более одной сборки — надеюсь, из гибкой инфраструктуры.
Переключаемое состояние во время выполнения программы
Иногда флагов, заданных при запуске приложения, недостаточно. Допустим, вы авиакомпания, продающая билеты на рейсы через Интернет. Вы также можете сдавать автомобили в аренду в сотрудничестве с партнером, скажем, «Really Cool Rental Cars» (RCRC). Подключение к любому партнеру или проверка текущего статуса его системы находится вне вашего контроля, поэтому вам может потребоваться переключатель в программном обеспечении, который работает без перезапуска, чтобы включить или выключить “резервирование партнеров RCRC” и дать возможность группе поддержки переключить его, если определенные условия “Runbook” были соблюдены. В этом случае конечные пользователи могут не заметить, все ли Hertz, Avis, Enterprise и т.д. (сервисы проката автомобилей — прим. пер.) находятся в предложениях для этого аэропорта во время прибытия рейса.
Ключевым моментом для переключаемых флагов во время выполнения является необходимость сохранения состояния. При перезапуске приложения или службы не следует возвращать этот флаг по умолчанию — он должен сохранить предыдущее значение. Все усложняется когда вам нужно чтобы флаг пронизывал несколько узлов в кластере горизонтально масштабируемых родственных процессов. Для этого случая существует современный способ фиксации состояние флага в Consul , Etcd или его эквиваленте.
Флаги сборки
Флаги сборки влияют на приложение или службу в процессе ее сборки. Что касается флага —withOneClickPurchase , то приложение не сможет во время выполнения иметь эту возможность, если каким-то образом во время сборки подходящий флаг не был задан.
A/B тестирование и бета версии
Отправка кода, который выключен в рабочей среде, позволяет вам включить его по разным причинам — например, вы хотите чтобы какая-то часть пользователей явно или не явно проверила его. A/B тестирование (которое так любит маркетинг) возможно с флагами, которые могут менчть свое значение во время работы программы. Таким образом, есть бета версии функционала/отдельных функций, которые доступных для определенных групп пользователей.
Технический долг — это ловушка
Флаги со временем копятся в кодовые базы и часто забываются, когда команды разработчиков стремятся к новым бизнес-результатам. Конечно, вы хотите подождать некоторое время, пока не станет ясно, что вы поняли какое именно состояние флага вам подходит лучше всего, и именно в этом проблема — приложение отлично работает с флагом, оставленным на месте, и бизнес действительно заботится только о новых приоритетах. Единственное спасение — это то, что у вас были unit тесты для всего, даже для кода, который фактически отключен в производственной среде. Постарайтесь договориться с бизнесом разрешить удаление флагов (и кода, к которому они применяются) через месяц после выпуска. Может быть, добавить их в README проекта с датой «проверки на удаление».
История
Некоторые исторические предшественники переключателей/флагов функций, какими мы их знаем сегодня:
- нифицированное управление версиями с помощью логики функций (Andreas Zeller and Gregor Snelting, 1996) — официальная публикация.
- Управление конфигурацией с наборами версий: унифицированная модель управления версиями программного обеспечения и ее приложений (Andreas Zeller’s, 1997) — Ph.D. тезис.
Также есть предупреждение:
- “#ifdef считается вредным” (Henry Spencer and Geoff Collyer, 1992) — официальная публикация.
Бред Эплтон (Brad Appleton) сказал:
“ Что мне не нравится в переключателях функций/флагах, так это то, что они НЕ являются недолговечными, как предполагалось, и нам приходится возвращаться к знаменитой статье Спенсера и Коллайера. Самое смешное, что ветки для функций (feature-branches) появаились точно таким же путем. Когда они были впервые представлены, это предназначалось для функциональных команд, разрабатывающих очень большие функции, а отдельные ветки для функций были нужны потому, что слишком много людей пытались одновременно влить код в одну и ту же ветку. Таким образом, идея заключалась в использовании отдельных ветвей (для масштабирования), и команды могли бы интегрироваться в свою командную ветвь ежедневно или чаще с интеграцией по крайней мере каждую ночь по всем функциональным веткам [вздох].
Источник: trunkbaseddevelopment.ru
Использование флага (переменная булевого типа) для начинающих
Например есть такая задача перебрать данные и определить есть ли там нужные нам для примера возьмем ситуацию из жизни: переберем мешок с картошкой, нужно узнать есть ли там гнилая мешок представим списком [] из 1 и 2, где 1 — означает гнилую картофелину.
Как бы мы это делали? сначала мы бы взяли одну картофелину и посмотрели на нее, и так делали бы до конца или пока не встретили гнилую.
А в конце основываясь на наблюдениях делали бы выводы.
На словах все понятно, но когда смотришь код тех кто только еще познает питона, то в коде они так и норовят делать вывод о присутствии(или о том что нету гнилых) сразу на первой же картошке.
Пример ошибочного поведения в коде:
bag_potatoes = [2, 2, 2, 1, 2, 1, 2, 2, 2, 2] # это наш мешок, в нем 2 гнилушки for potato in bag_potatoes: # запустим цикл перебора картошки if potato == 1: print(‘Замечена гнилая картошка’) print(‘Нужно сходить выкинуть, то что нашли’) else: print(‘Нет гнилой картошки’) print(‘Ничего выкидывать не нужно’)
Вот тут в блоке else и кроется ошибка, т. е. мы еще не закончили перебирать мешок, а выводы уже делаем.
Попробуем решить с флагом:
bag_potatoes = [2, 2, 2, 1, 2, 1, 2, 2, 2, 2] # это наш мешок, в нем 2 гнилушки rot_flag = False # это наш флаг на гниль, сейчас у него значение фолз (ложь) for potato in bag_potatoes: # запустим цикл перебора картошки if potato == 1: rot_flag = True # замечена гнилая картошка, флаг мы переводим в Тру (истина) # ниже мы смотрим на значение флага, т.е. наших наблюдений, и делаем выводы if rot_flag: print(‘есть гнилая картошка’) print(‘Нужно сходить выкинуть, то что нашли’) else: print(‘нет гнилой картошки’) print(‘Ничего выкидывать не нужно’)
А как же можно научиться пользоваться флагом?
Мне например помог счетчик…
Пример: посчитаем гнилую картошку:
bag_potatoes = [2, 2, 2, 1, 2, 1, 2, 2, 2, 2] # это наш мешок, в нем 2 гнилушки count = 0 # счетчик на гниль for potato in bag_potatoes: # запустим цикл перебора картошки if potato == 1: count += 1 # замечена гнилая картошка, увеличиваем счетчик if count > 0: # смотрим что насчитали и делаем выводы print(‘есть гнилая картошка’) print(‘Нужно сходить выкинуть, то что нашли’) else: print(‘нет гнилой картошки’) print(‘Ничего выкидывать не нужно’)
Следующий шаг на пути счетчик-флаг понимание того что нам не нужно считать, а достаточно изменить счетчик с 0 на любое число, например 1
for potato in bag_potatoes: # запустим цикл перебора картошки if potato == 1: count = 1 # замечена гнилая картошка, меняем счетчик if count == 1: # смотрим на счетчик и делаем выводы print(‘есть гнилая картошка’) print(‘Нужно сходить выкинуть, то что нашли’) else: print(‘нет гнилой картошки’) print(‘Ничего выкидывать не нужно’)
Но наш счетчик уже не счетчик, у него 2 возможных значения (0, 1)
А это прям подходит для булевых переменных, которые и являются классическим флагом со значениями (True, False)
Вот мы сменили значения 0 на False, 1 на True
Теперь если сменить имя счетчика count на rot_flag, то получится первый вариант решения, т. е. с полноценным флагом.
Это не идеальная задача.
На этой задаче я попытался показать его работу и как его понять можно с помощью счетчика, считать перебор многим дается легче на восприятии чем понятие «индикатор» или флаг.
PS. Благодарен друзьям за поддержку и идею создания статьи.
- флаг
- булевы переменные
Источник: habr.com