В процессе работы над PersMarket регулярно появляются новые возможности, которые должны быть видны не сразу или не всем. Для таких целей придумали специальный подход - Feature flags (или feature toggles). Я уже упоминал его ранее, когда писал про минимизацию рисков и даунтайма при деплое. Заключается подход в том, чтобы была возможность включать, выключать или менять поведение отдельных функций приложения в реальном времени без повторного деплоя. То есть код и настройки фичи выкатываются очередным релизом, но где-то в базе/конфигах есть переключатель/флаг, по умолчанию выключенный, от состояния которого зависит, работает ли эта функция. И когда приходит момент, флаг просто включают, и пользователи сразу видят новые ништяки. Например, функция оплаты актуальна только после всех согласований с платежным провайдером и обновления юридических документов, хотя код уже должен существовать, чтобы протестировать процессы.

Кстати, имея опыт работы со Stripe, подключал Робокассу. После современных API-управляемых возможностей Stripe Робокасса выглядит, как что-то из нулевых. В Stripe можно построить полноценный тестовый контур, с автотестами, с подписками, платежами, рефандами и т.д. В Робокассе можно сделать только тестовый разовый платеж без истории. То есть узнать его статус позже нельзя, он не хранится. А возвраты и рекуррентные платежи вообще не поддерживают тестирование. Надо будет попробовать других провайдеров еще для сравнения.

Еще сценарии: ▪️Если в функции есть критичный баг, ее можно отключить мгновенно без передеплоя ▪️Можно сделать канареечный релиз - включать функцию сначала малой аудитории, потом больше и больше ▪️Можно проводить A/B-тестирование ▪️Можно тестировать функцию прямо из мастер-ветки (особенно в trunk-based разработке), не включая ее на проде Вот и я себе сделал в админке сервиса такой пункт управления, чтобы включать фичи по мере готовности к ним платформы. А оказывается, есть и готовые решения: Split, Flagsmith, LaunchDarkly, GrowthBook, Unleash. А для PHP - Flagception. Конечно, не всё коту масленица, есть и минусы. Во-первых, появляются условия - сценарии для включенной функции и для выключенной, это усложнение. Во-вторых, если необходимость управления фичей отпадает, появляется технический долг - условия и feature flags надо удалять, а до этого обычно руки не доходят. Короче, знайте меру. #process

Путь к ИИ-сингулярности Карпати описал вайбкодинг как зарисовку про выходные и одноразовые проекты. Дядя пошутил, а индустрия прочитала это как методологию. MVP собирается за вечер, в пятницу едет в прод, в понедельник приходят первые пользователи, а во вторник летят вопросы в духе «а почему я вижу чужие данные» и «где моя собака?». Потом стали чинить это правилами: через месяц в файле тысяча строк, половина капслоком, треть противоречит остальному, и агент всё это честно читает. Велосипеду два года добавляли то руль побольше, то колесо покруглее, то моторчик, то спидометр, а седло забывали каждый раз. Ехать можно, даже эффектно, просто через несколько месяцев выясняется, где именно болит. В исследовании METR опытные разработчики в своих же зрелых репозиториях возились с задачами на 19% дольше, оставаясь убеждёнными, что стали быстрее. Проедемся по всей хронологии и посмотрим, на каком этапе что отваливалось.

Басня о полусыром продукте Печь, которую собирает компания из этой притчи, умеет добавлять свечи на торт, подключаться к камину и работать в режиме «Рамадан». Одного не умеет — стабильно печь: хлеб и торты подгорают в каждом десятом случае. Инженеры однажды нашли выход, стоит убрать из печи один из трёх видов выпечки, и брак падает с трети случаев до 5%. Учредитель запретил. Он обещал инвесторам весь рынок, и теперь ему оставалось выбрать, какое из обещаний нарушить. Дальше история катится сама. Каждая новая кнопка добавляется дольше предыдущей, клиенты возвращают печь через неделю, а служба поддержки уговаривает остаться, обещая ещё один релиз. Замените печь на любой продукт, который вы разрабатывали.