Feature flags и A/B-эксперименты: выкатывать безопасно и измерять

Feature flags (флаги возможностей) — простая идея с большими последствиями: вы отделяете момент, когда код попадает на прод (деплой), от момента, когда он начинает работать для пользователей (включение фичи). Это меняет модель релизов. Что это даёт. (1) Kill switch — мгновенно выключить проблемную фичу без отката деплоя; в отличие от redeploy, занимает секунды. (2) Канареечный релиз — включить на 1% трафика, посмотреть на метрики, расширить до 100%. (3) A/B-эксперименты — случайно разделить пользователей на группы, измерить эффект от изменения. (4) Бета для части пользователей. (5) Релиз по подписке (early access). Категории флагов: release-флаги (короткоживущие, пока фича раскатывается), experiment-флаги (привязаны к A/B-тесту, живут пока идёт эксперимент), ops-флаги (kill switch, долгоживущие), permission-флаги (роль/подписка пользователя). Что выбрать. SaaS-решения (LaunchDarkly, ConfigCat) — быстро стартуют, но платят за объём и вводят внешнюю зависимость в критический путь. Open-source (Unleash, Flagsmith) — разворачиваются у себя, без vendor lock-in. Своя реализация — соблазн, но легко недооценить: кеширование на стороне клиента, консистентность между сервисами, аудит, rollout-проценты. Главный риск — технический долг флагов: забытые флаги от давно выпущенных фич превращают кодовую базу в лабиринт `if (flag)`. Дисциплина: expiration-дата на release-флагах, регулярный аудит и удаление «мёртвых» веток кода.

• #feature-flags
• #ab-testing
• #release
• #experimentation

Дизайн-системы: когда они окупаются, а когда это оверинжиниринг

«Дизайн-система» — ещё одно слово, которое стало означать слишком многое: от набора Figma-стиков до полноценного продукта с командой и релизами. Разберём, что это такое и когда окупается. Дизайн-система — это не UI-кит. UI-кит (набор кнопок и инпутов) — её часть, но система шире: это набор принципов, токенов дизайна (colors, spacing, typography как переменные), переиспользуемых паттернов, документации, гайдлайнов по применению, и процесса поддержки. Цель — единый визуальный и UX-язык между командами и продуктами, чтобы кнопка выглядела и вела себя одинаково везде. Когда окупается. (1) Несколько продуктов или платформ (web+mobile+desktop) в одной компании — без системы они расходятся в деталях. (2) Много команд — единая система убирает дублирование и споры «как сделать карточку». (3) Долгий жизненный цикл — дизайн-система окупается через 1–2 года, на коротких проектах не успеет. Когда это оверинжиниринг. Маленький продукт с одной командой — хватит общего файла стилей и набора компонентов. Стартап в поиске продуктовой ниши — UI ещё не устоялся, инвестиции в систему уйдут в мусор после следующего пивота. Главный риск: дизайн-система — это отдельный продукт со своим бэклогом, версионированием, депрекациями. Если нет людей, готовых её поддерживать (дизайн + разраб), она превратится в «заброшенную библиотеку», которой никто не пользуется. Признак здоровой системы — её используют добровольно, потому что это быстрее, чем делать своё.

• #design-system
• #ui-kit
• #design-tokens
• #product

Accessibility для разработчика: WCAG, ARIA, контраст

Доступность (accessibility, a11y) часто воспринимают как «заботу о малом меньшинстве», но это не точно. По данным ВОЗ, около 16% населения мира имеют ту или иную форму инвалидности — это сотни миллионов потенциальных пользователей; кроме того, доступность помогает и всем остальным: людей с временными травмами, на ярком солнце, в шумной среде. А в юрисдикциях вроде ЕС и США для ряда продуктов она обязательна по закону (European Accessibility Act 2025, ADA). Что реально делать разработчику. WCAG (Web Content Accessibility Guidelines) — стандарт с тремя уровнями соответствия (A, AA, AAA); для большинства коммерческих сайтов ориентир — AA. Семантический HTML решает 70% проблем: `<button>` вместо `<div onclick>`, `<label>` для инпутов, правильные заголовки (`<h1>` → `<h2>` иерархией), `<nav>`, `<main>`, `<section>`. Screen reader читают DOM-дерево, и семантика — их основной канал. ARIA — там, где семантики не хватает (кастомные виджеты, динамические регионы): `aria-label`, `aria-expanded`, `aria-live`. Правило №1 ARIA: «первое правило ARIA — не использовать ARIA», если есть нативный HTML-элемент. Клавиатурная навигация: всё доступно через Tab, виден focus-ring (не убирайте `outline` без замены). Контраст: минимум 4.5:1 для обычного текста по WCAG AA — проверяйте через WebAIM Contrast Checker. Конкретные грабли: `display:none` (скринридер не читает), `tabindex` больше 0, картинки без `alt`, только цвет для различения статусов.

• #accessibility
• #a11y
• #wcag
• #aria
• #frontend

Технический долг: как его считать, обсуждать с бизнесом и гасить

Термин «технический долг» Уорд Каннингем ввёл именно как метафору с деньгами: вы берёте в долг (быстрое решение), чтобы быстрее выпустить фичу, и платите проценты (замедление следующих релизов) до тех пор, пока не вернете долг (рефакторинг). Как любая метафора, она ломается, если её понять буквально. Разбираем по слоям. (1) Революционный (осознанный) долг — «мы знаем, что это костыль, выпускаем к сроку, занесём в бэклог». Это нормальный инструмент, если долг осознан и запланирован к возврату. (2) Эволюционный (неосознанный) долг — код писался нормально, но требования изменились, и архитектура перестала им соответствовать. Не вина автора, а свойство развивающейся системы. (3) Гнилостный долг — код низкого качества, который копируется и плодится. Самый дорогой. «Проценты» технического долга измеряются не в строчках, а в скорости: сколько времени занимает новая фича в этой части кода, и насколько это дольше, чем могло бы быть. Как обсуждать с бизнесом: не «нам надо отрефакторить» (бизнесу всё равно), а «эта фича сейчас занимает 5 дней из-за запутанного модуля; рефакторинг снизит до 1 дня, и каждая следующая фича в этой области будет дешевле». Перевод в деньги и срок окупаемости — единственный язык, который понимает стейкхолдер. Главное правило погашения: никогда «не переписать всё с нуля