DEV Community: Nubami SQReder

Either-like Monads to automate Feature Toggles

Nubami SQReder — Fri, 21 Mar 2025 13:43:04 +0000

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

Если зашло — заглядывай в мой телеграм-канал, там ещё больше лайфхаков для разработчиков

Последние несколько лет я работал по Git Flow, и меня всё устраивало. Много веток, понятная структура, классика жанра. Но с ростом команды и продукта проявилась серьёзная проблема - потерянные коммиты между ветками релизов и внезапный регресс функциональности.

Ситуация немного облегчалась тем, что в BitBucket есть автомерж. Он сам следит, чтобы релизы были вмержены по-порядку и создаёт PR при необходимости. Но после того как BitBucket импортозаместили на Сферу - стало сильно сложнее, т.к. автомержей туда пока не завезли 🤷‍♂️

Когда в очередной раз обнаружилось, что фикс из одного релиза не попал в следующий, я задумался о переходе на Trunk-Based Development (TBD)¹ — подход с одной основной веткой и фичефлагами для управления функциональностью.

Главное препятствие для перехода на TBD в нашем случае — длинные циклы разработки и необходимость поддерживать несколько параллельных релизов с разным набором фич. Добавлять фичефлаги на каждую новую функцию технически несложно, но вести их учет и управлять включением/выключением для нужного релиза — задача нетривиальная и скучная. Да, в целом, эта задача у нас ложится на аналитиков и QA, но лучшая работа — та, которую не нужно делать

Disclaimer: На самом деле, после написания этого поста я успел еще подумать и полностью переделать API. Но хочу рассказать о пройденном пути и как развивалось моё видение

Первый заход

Ключевая идея, которая пришла мне в голову - можно включать фичу автоматически, ориентируясь на версию из package.json. Мы почти наверняка знаем в каком релизе вы выводим функционал, поэтому почему-бы не сравнить версии используя semver, и на основе этого выбрать вариант

const logger = releaseOn({
  currentVersion: PACKAGE_VERSION,
  targetVersion: "3.6.0",
  legacy: console,
  release: prettyLogger,
});

Реализация тут прямолинейная:

👆 Развернуть

import semver from "semver";

type ReleaseOnConfig<T, U> = {
  currentVersion: string;
  targetVersion: string;
  legacy: T;
  release: U;
};

function releaseOn<T, U>(params: ReleaseOnConfig<T, U>): T | U {
  if (semver.lt(params.currentVersion, params.targetVersion)) {
    return params.legacy;
  } else {
    return params.release;
  }
}

✅ Автоматическое включение функционала при обновлении версии
✅ Предсказуемое поведение на основе семантического версионирования
✅ Удобно для фичей, которые должны быть целиком включены или выключены в определенной версии

❌ Каждый переключатель нужно указывать отдельно — бойлерплейтно
❌ Потенциальные проблемы с типизацией при использовании разных типов данных для legacy и release
❌ При изменении планов релиза нужно обновлять все переключатели руками 😒

Будем понемногу разбираться с минусами и начнём по порядку

Боремся с бойлерплейтом

Одно место у нас точно постоянное - версия самого приложения. Ни к чему передавать её в каждом вызове. Значит, вынесем в фабрику, которая будет хранить значение в замыкании

const releaseOn = makeReleaseToggle({ currentVersion: PACKAGE_VERSION });

const logger = releaseOn({
  targetVersion: "3.6.0",
  legacy: console,
  release: prettyLogger,
});

const value = releaseOn({
  targetVersion: "3.6.0",
  legacy: oldValue,
  release: newValue,
});

logger.log(value);

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

const releaseOn = makeReleaseToggle({ currentVersion: PACKAGE_VERSION });

const toggle = releaseOn("3.6.0");

const logger = toggle({ legacy: console, release: prettyLogger });
const value = toggle({ legacy: oldValue, release: newValue });

logger.log(value);

Реализация опять-же не должна вызвать затруднений:

👆 Развернуть

type ReleaseToggleConfig = { currentVersion: string };

const makeReleaseToggle = (config: ReleaseToggleConfig) => {
  const { currentVersion } = config;

  return (targetVersion: string) => {
    const shouldUseRelease = semver.gte(currentVersion, targetVersion);

    return <L, R>(options: { legacy: L; release: R }): L | R => {
      return shouldUseRelease ? options.release : options.legacy;
    };
  };
};

✅ Меньше бойлерплейта
✅ Централизованное управление переключениями для связанных компонентов через общий toggle

❌ Нет возможности легко тестировать варианты без изменения версии
❌ Отсутствует понимание того, какие флаги активны в текущей сборке
❌ Остается риск "мертвого" кода, если забыть удалить legacy-логику после релиза и стабилизации
❌ Проблемы с типизацией при использовании разных типов данных для legacy и release

Устраняем неочевидности

Решим первые три проблемы разом, добавив:

Описательные метаданные — каждый переключатель будет содержать описание
Автоматическое логирование — при создании переключателя его состояние фиксируется в консоли
Механизм принудительного переключения — через явное указание состояния флага, вместо версии для активации
Умные предупреждения — система автоматически уведомит нас об устаревших фичефлагах

Вот как это будет выглядеть при использовании:

const releaseOn = makeReleaseToggle({ currentVersion: "3.7.0" });

// logs `'TASK-1234 For 3.8.0' not yet released`
const toggle = releaseOn({
  targetVersion: "3.8.0",
  description: "TASK-1234 For 3.8.0",
});

// logs `Use release version for 'TASK-2345 For 3.7.0'`
const toggle = releaseOn({
  targetVersion: "3.7.0",
  description: "TASK-2345 For 3.7.0",
});

// logs `Use release version for 'TASK-0123 For 3.6.0'`
// warns `Feature toggle target for 'TASK-0123 For 3.6.0' is less than current version. Consider to remove toggle`
const toggle = releaseOn({
  targetVersion: "3.6.0",
  description: "TASK-0123 For 3.6.0",
});

declare const FF_OVERRIDE_VARIANT: 'legacy' | 'release';

const toggle = releaseOn({
  overideVariant: FF_OVERRIDE_VARIANT,
  targetVersion: "3.6.0",
  description: "TASK-0123 For 3.6.0, but may be overrided in runtime",
});

Реализация чуть более замороченная:

👆 Развернуть

type ReleaseToggleConfig = { currentVersion: string };
type ToggleOptions = {
  targetVersion: string;
  description: string;
  overrideVariant?: "legacy" | "release";
};

// Improved implementation with logging capabilities
const makeReleaseToggle = (config: ReleaseToggleConfig) => {
  const { currentVersion } = config;

  return (options: ToggleOptions) => {
    const { targetVersion, description, overrideVariant } = options;

    // Determine if the feature should be released based on version comparison
    const versionDiff = semver.compare(targetVersion, currentVersion);
    const isReleased = versionDiff <= 0;

    // Log appropriate messages based on release status
    if (overrideVariant) {
      console.log(`[TOGGLE] Override to '${overrideVariant}' version for '${description}'`);
    } else if (isReleased) {
      console.log(`[TOGGLE] Use release version for '${description}'`);

      if (versionDiff < 0) {
        console.warn(
          `[TOGGLE] Feature toggle target for '${description}' is less than current version. Consider removing toggle`
        );
      }
    } else {
      console.log(`[TOGGLE] '${description}' not yet released`);
    }

    // Return the toggle function that selects between legacy and release implementations
    return <L, R>(options: { legacy: L; release: R }): L | R => {
      if (overrideVariant === "legacy") return options.legacy;
      if (overrideVariant === "release") return options.release;

      return isReleased ? options.release : options.legacy;
    };
  };
};

Здорово? Офигенно!

Настало время заняться типизацией!

Управляемся с типами на выходе: знакомимся с монадами

Наконец-то мы добрались до монад! Я давно пользуюсь FP-подходами, но долгое время не мог врубиться что такое эти ваши монады – всё объяснялось либо чересчур абстрактно, либо примитивно до бессмысленности. Недавно у меня наконец-то щёлкнуло, и я целый пост об этом написал.

Что такое монада простыми словами?

Монада — это контейнер для значения с дополнительным контекстом. По сути, это просто объект, который:

Умеет заворачивать обычное значение в себя (метод of)
Позволяет применять к внутреннему значению функции, не разворачивая его каждый раз вручную (метод chain)

Примеры монад, которыми мы постоянно пользуемся:

Maybe — значение, которое может отсутствовать
Either — значение, которое может быть либо корректным, либо ошибкой
Promise — не совсем монада, но очень похоже (и вы с ним уже точно работали)

Весь сок именно в Either — он выглядит идеальным для нашей задачи переключения между двумя реализациями!

Either - выглядит очень интересно!

Either позволяет очень удобно выбирать из двух вариантов. Но есть нюанс — у нас нет правильного и неправильного варианта.

В Either у нас Left/Right, а мы назовём Legacy/Release. Оммаж, так сказать.

type Legacy<L> = { legacy: L; release?: never };
type Release<R> = { legacy?: never; release: R };

type Either<L, R> = NonNullable<Legacy<L> | Release<R>>;

Конструкция field?: never тут для следующего:

помогает указать, что оба типа имеют одинаковые поля, благодаря чему получается аккуратное пересечение типов
never явно указывает, что никакого значения в поле быть не может
?: показывает, что поле опциональное и может пропускаться при объявлении соответствующего объекта

Добавим к этому делу пару хелперов:

// быстрое создание новых значений
const makeLegacy = <L>(value: L): Legacy<L> => ({ legacy: value });
const makeRelease = <R>(value: R): Release<R> => ({ release: value });

// type guards для проверки какое значение перед нами
function isLegacy<L, R>(either: Either<L, R>): either is Legacy<L> {
  return "legacy" in either && either.legacy !== undefined;
}

function isRelease<L, R>(either: Either<L, R>): either is Release<R> {
  return "release" in either && either.release !== undefined;
}

function absurd(value: never): never {
  // Эта функция используется для исчерпывающей проверки типов
  // Она гарантирует, что все возможные случаи обработаны на этапе компиляции
  // Если вызывается во время выполнения, значит мы достигли невозможного состояния
  throw new Error(`Reached impossible state: ${JSON.stringify(value)}`);
}

ℹ️ По поводу того что за утилита absurd можно почитать тут²

Теперь можно гораздо удобнее обходиться с результатом переключения функционала

const logger = toggle({ legacy: console, release: prettyLogger }); // Either<Console, PrettyLogger>

if (isLegacy(logger)) {
  logger.legacy.log(`Good 'ol console`);
} else if (isRelease(logger)) {
  logger.release.log(`Brand new logging possibilities`);
} else {
  // absurd не обязательный, но будет ругаться если мы обработаем не все варианты
  absurd(logger);
}

Откровенно говоря, вот эти logger.legacy и logger.release тоже не прикольные. Поэтому сделаем еще оператор, который будет извлекать из Either нужное значение, да еще и с правильным типом.

const union = unwrap(either); // Console | PrettyLogger

if (isLegacy(either)) {
  const logger = unwrap(either); // Console
} else if (isRelease(either)) {
  const logger = unwrap(either); // PrettyLogger
} else {
  absurd(either);
}

Для красивого вывода типов используем перегрузку функций³:

👆 Развернуть

function unwrap<L>(legacy: Legacy<L>): NonNullable<L>;
function unwrap<R>(release: Release<R>): NonNullable<R>;
function unwrap<L, R>(either: Either<L, R>): NonNullable<L | R>;

function unwrap<L, R>(either: Either<L, R>): NonNullable<L | R> {
  if (either.legacy !== undefined && either.release !== undefined) {
    throw new Error("Received both legacy and release values at runtime when opening an Either");
  } else if (either.legacy !== null) {
    return either.legacy;
  } else if (either.release !== null) {
    return either.release;
  } else {
    throw new Error(`Received no legacy or release values at runtime when opening Either`);
  }
}

В целом удобнее. Но, что если мы хотим как-то обрабатывать или изменять значения в Either и пробрасывать их дальше?

Chaining

Каждый раз писать громоздкую конструкцию из if совсем не хочется.

Помните, что Promise это тоже монада? У Promise есть метод .then(success, failure). В лексиконе FP он может называться map или chain (знатоки, не придирайтесь, пожалуйста). Вот его мы и реализуем.

function map<L, R, T, U>(
  either: Either<L, R>,
  onLegacy: (legacy: NonNullable<L>) => T,
  onRelease: (release: NonNullable<R>) => U
): Either<T, U> {
  if (isLegacy(either)) {
    return makeLegacy(onLegacy(either.legacy));
  } else if (isRelease(either)) {
    return makeRelease(onRelease(either.release));
  } else {
    return absurd(either);
  }
}

// Usage example:
const result = map(
  either,
  (console) => console.log("Using legacy logger"),
  (prettyLogger) => prettyLogger.prettyLog("Using new pretty logger")
);

// Or with more complex transformations:
const tag = "Auth";
const prefixedLogEither = map(
  either,
  (console) =>
    (...values: unknown[]) =>
      console.log(`[${tag}]`, ...values),
  (prettyLogger) => prettyLogger.tagged(tag)
);

const prefixedLog = unwrap(prefixedLogEither);

Промежуточный итог

Итак, у нас есть монады, unwrap, map и другие полезные функции для работы с нашим Either-подобным типом. Подведем итоги и посмотрим, как это все работает на практике.

Полная реализация

Давайте соберем все части воедино:

👆 Развернуть

import semver from "semver";

// Either type definition
type Legacy<L> = { legacy: L; release?: never };
type Release<R> = { legacy?: never; release: R };
type Either<L, R> = NonNullable<Legacy<L> | Release<R>>;

// Either helpers
const makeLegacy = <L>(value: L): Legacy<L> => ({ legacy: value });
const makeRelease = <R>(value: R): Release<R> => ({ release: value });

function isLegacy<L, R>(either: Either<L, R>): either is Legacy<L> {
  return "legacy" in either && either.legacy !== undefined;
}

function isRelease<L, R>(either: Either<L, R>): either is Release<R> {
  return "release" in either && either.release !== undefined;
}

function unwrap<L, R>(either: Either<L, R>): NonNullable<L | R> {
  if (isLegacy(either)) {
    return either.legacy as NonNullable<L>;
  } else if (isRelease(either)) {
    return either.release as NonNullable<R>;
  } else {
    throw new Error(`Received no legacy or release values at runtime when opening Either`);
  }
}

function map<L, R, T, U>(
  either: Either<L, R>,
  onLegacy: (legacy: NonNullable<L>) => T,
  onRelease: (release: NonNullable<R>) => U
): Either<T, U> {
  if (isLegacy(either)) {
    return makeLegacy(onLegacy(either.legacy as NonNullable<L>));
  } else if (isRelease(either)) {
    return makeRelease(onRelease(either.release as NonNullable<R>));
  } else {
    throw new Error("Invalid Either value");
  }
}

// Release toggle implementation
type ReleaseToggleConfig = { currentVersion: string };

type ToggleOptions = {
  targetVersion: string;
  description: string;
  overrideVariant?: "legacy" | "release";
};

const makeReleaseToggle = (config: ReleaseToggleConfig) => {
  const { currentVersion } = config;

  return (options: ToggleOptions) => {
    const { targetVersion, description, overrideVariant } = options;

    // Determine if the feature should be released based on version comparison
    const versionDiff = semver.compare(targetVersion, currentVersion);
    const isReleased = versionDiff <= 0;

    // Log appropriate messages based on release status
    if (overrideVariant) {
      console.log(`[TOGGLE] Override to '${overrideVariant}' version for '${description}'`);
    } else if (isReleased) {
      console.log(`[TOGGLE] Use release version for '${description}'`);

      if (versionDiff < 0) {
        console.warn(
          `[TOGGLE] Feature toggle target for '${description}' is less than current version. Consider removing toggle`
        );
      }
    } else {
      console.log(`[TOGGLE] '${description}' not yet released`);
    }

    // Return the toggle function that creates appropriate Either
    return <L, R>(options: { legacy: L; release: R }): Either<L, R> => {
      const { legacy, release } = options;

      if (overrideVariant === "legacy") return makeLegacy(legacy);
      if (overrideVariant === "release") return makeRelease(release);

      return isReleased ? makeRelease(release) : makeLegacy(legacy);
    };
  };
};

Практическое применение

Рассмотрим несколько сценариев использования нашего решения:

Пример 1: Переключение между реализациями логгера

// Инициализация
const PACKAGE_VERSION = "3.7.0";
const releaseOn = makeReleaseToggle({ currentVersion: PACKAGE_VERSION });

// Создание переключателя для конкретной фичи
const loggerToggle = releaseOn({
  targetVersion: "3.8.0",
  description: "TASK-1234: Enhanced logging system",
});

// Определение старого и нового логгера
const legacyLogger = {
  log: (message: string) => console.log(message),
  error: (message: string) => console.error(message),
};

const newLogger = {
  log: (message: string) => console.log(`[INFO] ${message}`),
  error: (message: string) => console.error(`[ERROR] ${message}`),
  debug: (message: string) => console.log(`[DEBUG] ${message}`),
};

// Использование
const logger = loggerToggle({ legacy: legacyLogger, release: newLogger });

// Вариант 1: Проверка типа и использование
if (isLegacy(logger)) {
  logger.legacy.log("Using legacy logger");
} else {
  logger.release.log("Using new logger");
  logger.release.debug("Debug info available only in new logger");
}

// Вариант 2: Извлечение значения
const actualLogger = unwrap(logger);
actualLogger.log("This works with both implementations");

// Применение операций, сохраняющих Either
const taggedLogger = map(
  logger,
  (legacy) => ({
    log: (message: string) => legacy.log(`[Auth] ${message}`),
    error: (message: string) => legacy.error(`[Auth] ${message}`),
  }),
  (release) => ({
    log: (message: string) => release.log(`[Auth] ${message}`),
    error: (message: string) => release.error(`[Auth] ${message}`),
    debug: (message: string) => release.debug(`[Auth] ${message}`),
  })
);

// ... unwrap(taggedLogger).log('There will be tag')

Пример 2: Переключение компонентов UI

// Определяем переключатель для новой формы регистрации
const registerFormToggle = releaseOn({
  targetVersion: "3.7.0",
  description: "TASK-5678: Improved registration form",
});

// Использование в React-компоненте
function Registration() {
  const formComponent = registerFormToggle({
    legacy: LegacyRegistrationForm,
    release: EnhancedRegistrationForm,
  });

  // Можно просто извлечь компонент
  const FormComponent = unwrap(formComponent);
  return <FormComponent />;

  // Или использовать условный рендеринг с типобезопасностью
  /*
  if (isLegacy(formComponent)) {
    return <formComponent.legacy showLegacyNote={true} />;
  } else {
    return <formComponent.release withNewFields={true} />;
  }
  */
}

Пример 3: Настройка через параметры окружения

// Настраиваем глобальный переключатель с возможностью переопределения
const FF_OVERRIDE = process.env.FEATURE_FLAG_OVERRIDE as "legacy" | "release" | undefined;

const releaseOn = makeReleaseToggle({ currentVersion: PACKAGE_VERSION });

const paymentSystemToggle = releaseOn({
  targetVersion: "3.9.0",
  description: "TASK-9012: New payment processing system",
  overrideVariant: FF_OVERRIDE,
});

// Использование
const paymentSystem = unwrap(
  paymentSystemToggle({
    legacy: legacyPaymentProcessor,
    release: newPaymentProcessor,
  })
);

async function processPayment(amount: number) {
  try {
    return await paymentSystem.process(amount);
  } catch (error) {
    console.error("Payment processing failed:", error);
    return null;
  }
}

Преимущества подхода

✅ Типобезопасность — TypeScript помогает отслеживать разницу между версиями реализаций
✅ Автоматизация — переключение происходит на основе версии, без ручного управления
✅ Прозрачность — логирование помогает видеть, какие переключатели активны
✅ Гибкость — можно переопределять поведение через параметры среды
✅ Чистый код — использование монад позволяет писать более декларативный код
✅ Удобство тестирования — можно легко тестировать обе реализации

Недостатки подхода

❌ Увеличение сложности — добавление монад и функциональных конструкций может усложнить код для разработчиков, не знакомых с FP
❌ Накладные расходы — дополнительный слой абстракции может привести к небольшому снижению производительности
❌ Кривая обучения — требуется время, чтобы команда освоила этот подход
❌ Риск забытого кода — несмотря на предупреждения, legacy-код может оставаться в репозитории дольше необходимого
❌ Зависимость от semver — корректная работа системы зависит от правильного версионирования
❌ Дополнительная инфраструктура — необходимо поддерживать систему логирования и мониторинга переключателей

Заключение

Этот подход сочетает:

Удобство feature toggles
Автоматизацию на основе семантического версионирования
Функциональное программирование с Either-like монадой

Это позволяет эффективно управлять функциональностью в условиях trunk-based development с параллельной разработкой нескольких релизов.

В конечном итоге, когда legacy-версия функционала становится ненужной (после нескольких релизов), переключатели можно безопасно удалить, ориентируясь на предупреждения в логах.

Если интересно дальше разбираться в концепциях полезных в повседневной работе — подписывайся на мой телеграм-канал

Я наконец понял, что такое монады (и ты сейчас тоже поймёшь)

Nubami SQReder — Wed, 12 Mar 2025 08:32:19 +0000

Привет! Я Андрей - техлид в бигтехе. Слежу за фронтом, налаживаю процессы, провожу собеседования, отстреливаю плохие практики и веду телеграм-канал обо всём этом. Сегодня расшифрую монады человеческим языком. Заглядывай в канал за другими сложными концепциями в простой форме!

Около пяти лет я использую подходы из функционального стиля программирования. Чистые функции, каррирование, reduce — всё это стало частью моего ежедневного кода. Но монады оставались для меня загадкой.

Я перечитал множество объяснений, но каждое оказывалось либо слишком абстрактным, либо чересчур упрощённым. Недавно произошло озарение: комбинация понимания Maybe, Either и аналогия с привычными Promise наконец сложились в понятную картину.

Делюсь своим пониманием простым языком, без сложных абстракций и запутанных метафор.

🧩 Что такое монада по-простому?

Монада — это абстракция для цепочки действий с контекстом. Звучит сложно? Согласен, давай объясню проще:

Представь, что у тебя есть значение, но с дополнительным "контекстом":

Значение может отсутствовать (Maybe)
Может случиться ошибка (Either)
Результат может появиться позже (Promise)

Каждая монада обязательно умеет делать две вещи:

of — запаковать обычное значение в монаду
chain (он же flatMap) — применить функцию, которая вернёт новую монаду

Есть ещё "три закона монад" (левый идентификатор, правый идентификатор и ассоциативность), но их можно изучить позже. Главное, что благодаря им всё работает предсказуемо.

🔍 Maybe — когда значение может отсутствовать

Знакомый код?

const name = user?.profile?.name ?? 'Аноним';

Это очень удобный синтаксис. Монада Maybe реализует ту же идею, но в более явной форме:

const Maybe = value => ({
  chain: fn => (value == null ? Maybe(null) : fn(value)),
  map: fn => Maybe(value == null ? null : fn(value)),
  fold: (none, some) => (value == null ? none() : some(value)),
  inspect: () => `Maybe(${value})`
});

Maybe(user)
  .map(u => u.profile)
  .map(p => p.name)
  .fold(() => "Аноним", name => name);

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

👀 Пример поинтереснее и более приближенный к реальности
👆 Развернуть

// Создаем переменные для повторного использования
const getProfile = u => u.profile;
const getSettings = p => p.settings;
const getPermissions = u => u.permissions;
const getAvatar = p => p.avatar;

// Функция для поиска пользователя по ID
// В реальном приложении это был бы запрос к API или базе данных
const findUserById = id => {
  // Моковые данные для примера
  const users = {
    1: {
      name: "Алексей",
      profile: {
        settings: { displayName: "Лёха" },
        avatar: { url: "/images/alex.jpg" }
      },
      permissions: { canEdit: true },
      lastLogin: "2023-05-15T10:30:00"
    },
    2: {
      name: "Мария",
      profile: {
        settings: { displayName: "Маша" },
      },
      permissions: { canEdit: false },
    }
  };

  // Возвращаем пользователя или null, если не найден
  return users[id] || null;
};

// ID пользователя для примеров ниже
const userId = 1; // Попробуй изменить на 2 или несуществующий ID

// Создаём Maybe(userId) и используем chain для безопасного поиска пользователя
// chain применяет функцию и возвращает новую монаду, избегая вложенности
const maybeUser = Maybe(userId).chain(id => findUserById(id));

// Получаем профиль пользователя, если пользователь существует
const maybeProfile = maybeUser.map(getProfile);

// Пример 1: Получение имени пользователя с проверкой на каждом шаге
maybeProfile
  .map(getSettings)
  .map(s => s.displayName)
  .fold(() => "Гость", name => name);

// Пример 2: Проверка прав доступа
maybeUser
  .map(getPermissions)
  .map(p => p.canEdit)
  .fold(() => false, canEdit => canEdit);

// Пример 3: Получение URL аватара с дефолтным значением
maybeProfile
  .map(getAvatar)
  .map(a => a.url)
  .fold(() => "/images/default-avatar.png", url => url);

// Пример 4: Цепочка с трансформацией данных
maybeUser
  .map(u => u.lastLogin)
  .map(date => new Date(date))
  .map(d => d.toLocaleDateString())
  .fold(() => "Никогда не входил", date => `Последний вход: ${date}`);

Интересно, что современные фичи JavaScript:

Optional Chaining (?.)
Nullish Coalescing (??)

По сути реализуют ту же идею, что и монада Maybe, но на уровне синтаксиса языка.

✅ Избавляет от вложенных проверок на null/undefined
✅ Делает код более декларативным и читаемым

❌ Придётся потратить пару часов на то, чтобы привыкнуть

⚔️ Either — когда нужно явно разделить успех и ошибку

Either — это монада с двумя состояниями:

Right — "правильный" результат
Left — ошибка или проблема

Вместо того чтобы бросать исключения или возвращать null, ты явно указываешь, что пошло не так:

Either.fromNullable(user)
  .chain(u => u.age >= 18 ? Right(u) : Left("Пользователь несовершеннолетний"))
  .fold(
    error => console.error("Ошибка:", error),
    user => console.log("Пользователь:", user)
  );

👀 Реализация и приближенный к реальности пример
👆 Развернуть

// Базовая имплементация Either
const Right = value => ({
  isRight: true,
  isLeft: false,
  map: f => Right(f(value)),
  chain: f => f(value),
  fold: (_, onRight) => onRight(value),
  inspect: () => `Right(${value})`
});

const Left = error => ({
  isRight: false,
  isLeft: true,
  map: _ => Left(error),
  chain: _ => Left(error),
  fold: (onLeft, _) => onLeft(error),
  inspect: () => `Left(${error})`
});

// Вспомогательные функции
const Either = {
  of: value => Right(value),
  fromNullable: value => value != null ? Right(value) : Left('Value is null or undefined'),
  tryCatch: (f) => {
    try {
      return Right(f());
    } catch (e) {
      return Left(e);
    }
  }
};

// Пример использования
const getUser = (id) => {
  // Имитация запроса к базе данных
  if (id === 123) {
    return Either.of({ id: 123, name: "Алексей", age: 30 });
  }
  return Left("Пользователь не найден");
};

// Валидация с Either
const validateUser = (user) =>
  user.age >= 18
    ? Right(user)
    : Left("Пользователь несовершеннолетний");

// Цепочка операций
getUser(123)
  .chain(validateUser)
  .fold(
    error => console.log(`Ошибка: ${error}`),
    user => console.log(`Привет, ${user.name}!`)
  );

✅ Делает обработку ошибок явной и предсказуемой
✅ Улучшает читаемость кода при сложной логике

❌ Названия Right и Left не очень интуитивны на первый взгляд
❌ Для некоторых сценариев может потребоваться дополнительный код

⏱️ Promise — это почти монада, и ты её уже знаешь

Интересно, что Promise в JavaScript — очень близок к монаде:

Promise.resolve(user)
  .then(u => u.profile)
  .then(p => p.name)
  .then(name => name ?? "Аноним")
  .then(console.log)
  .catch(console.error);

Метод .then() здесь выполняет роль монадического chain. А .catch() работает как обработчик ошибочного пути из Either.

Главное отличие в том, что Promise работает асинхронно и автоматически оборачивает возвращаемые значения.

💡 Что мне дали монады в реальной работе?

Когда я наконец разобрался с монадами, то обнаружил, что они решают вполне практические задачи:

✅ Упрощают сложные цепочки операций с проверками
✅ Делают код более предсказуемым и безопасным
✅ Снижают количество ветвлений и вложенных условий

На практике многие из нас уже используют монадоподобные подходы:

Цепочки .then() для промисов
Операторы ?. и ?? для безопасного доступа к свойствам

🌟 Монады на пальцах

Вот как бы я теперь объяснил монады:

"Монада — это способ связывать последовательные вычисления, особенно когда на каждом шаге что-то может пойти не так."

Roo Memory Bank prompt

Nubami SQReder — Thu, 20 Feb 2025 09:19:22 +0000

Итак, Cline мне не очень понравился своей аскетичностью, поэтому я решил продолжать свои исследования Memory Bank c Roo - всё-таки Roo — это Cline "на стероидах"

Но, прежде чем кидаться в омут с головой, я решил поискать, что в сети пишут про практику использования подхода. Наверняка есть рекомендации, специфические техники промптинга или даже примеры репозиториев, в которых видно, как MB живёт и развивается. Однако всё, что я нашёл, — это сплошной байт - "MB меняет всё полностью", "Супер-промпт", "Как же я в восторге от MB". И небольшие обзоры как скопировать промпт из репозитория и вставить в файл .clinerules. Не густо, и даже разочаровывающе

Штош. Придётся протаптывать дорожку самому

🧠 Memory Bank in the nutshell

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

Важное отличие Roo MB от Cline MB - то, как ведутся файлы с информацией о принятых решениях.

Cline

В Cline MB это довольно безликие techContext.md и systemPatterns.md

techContext.md

# Tech Context

This document outlines the technology choices and considerations for developing the progressive web app.

Current Considerations:
- Chosen framework: React, paired with Tanstack libraries (e.g., React Query, Tanstack Table) for building a responsive and scalable UI.
- No backend implementation exists yet; planning for secure user management and partner connection features.
- Focusing on Progressive Web App best practices including service workers, caching strategies, and offline capabilities.

Technical Debt & Future Considerations:
- Service worker caching strategy and optimization.
- Database backup and error logging frameworks.
- End-to-end encryption for partner data security.

The tech stack has been finalized to use React and associated Tanstack libraries, ensuring robust performance and modern development practices for the app.

## Core Dependencies (package.json requirements)
...

systemPatterns.md

# System Patterns

## Core Architecture
1. **Layered Context Providers**
   - AppSettingsContext: Global preferences
   - AuthContext: User session management
   - TaskContext: Daily tasks state

2. **Offline-First Strategy**
   - IndexedDB for local data persistence
   - Workbox Background Sync for failed requests
   - Optimistic UI updates with rollback capability

3. **Security Patterns**
   - JWT refresh token rotation
   - Encrypted localStorage for sensitive data
   - CSRF protection for API endpoints
...

Roo

Промпт для Roo, в свою очередь, предлагает чёткую структуру для описания принятых решений

## [Date] - [Decision Topic]

**Context:** [What led to this decision]
**Decision:** [What was decided]
**Rationale:** [Why this decision was made]
**Implementation:** [How it will be/was implemented]

Например, вот что у меня получилось на попытке стартовать проект с нуля

decisionLog.md

# Decision Log

## [2025-02-20] - [Development Environment]
**Context:** The user needs to initialize the project and configure the development environment.
**Decision:** Use React, styled-components, TypeScript, Vite, Vitest, and Playwright.
**Rationale:** These technologies are well-suited for building modern progressive web apps.
**Implementation:** The project will be initialized using Vite with the React TypeScript template.

## [2025-02-20] - [Vitest Configuration]
**Context:** The user wants to use globals for Vitest.
**Decision:** Configure Vitest to use globals by adding a `test` property to the `vite.config.ts` file.
**Rationale:** This allows for easier testing without having to import the Vitest functions in every test file.
**Implementation:** Added a `test` property to the `vite.config.ts` file with the `globals` option set to `true`.

## [2025-02-20] - [Styled-components Configuration]
**Context:** The user wants to use styled-components in the project.
**Decision:** Configure styled-components.
**Rationale:** Styled-components allows for writing CSS in JavaScript.
**Implementation:** Attempted to configure styled-components using the `@swc/plugin-styled-components` package, but was unsuccessful. Will proceed without the plugin for now.

...

Тут хорошо видно что делалось, когда и почему

⚡ Небольшой лайфхак

Если просить Roo что-то сделать, в духе "напиши-ка тесты", то он согласно инструкции начнёт читать свой MB по одному файлу. Можно немного сократить этот этап, если сразу передать их содержимое в контекст

follow your custom instructions and do the following:

{detailed task description}

Memory Bank content: @/memory-bank/

Эксперимент продолжается. Memory Bank в Roo, на первый взгляд, кажется куда структурированнее и понятнее, чем в Cline. Но хватит ли этого, чтобы оправдать его использование?

Продолжу копать, а если вам интересно следить за этим процессом — подписывайтесь на мой телеграм-канал: https://t.me/sqr_dev_moments.

🔗 Links

Roo Memory Bank GitHub

Roo Code: AI-разработчик в твоём VSCode (но за твои деньги)

Nubami SQReder — Mon, 17 Feb 2025 18:01:50 +0000

Я продолжаю челлендж "30 дней про AI для разработки", и этот пост — про Roo Code, расширение для VS Code, которое пытается стать твоим AI-напарником. Он может читать код, редактировать файлы, запускать команды и даже тесты, но при этом постоянно заставляет задуматься: а стоит ли оно того?

Я уже успел обжечься на токенах, удивиться его работоспособности и поразиться нелогичным решениям. В этом посте разберу что с Roo получилось, а что — нет.

Агентные инструменты: немного контекста

AI-ассистенты, которые не просто отвечают на вопросы, а могут выполнять задачи, появились давно. Это так называемые агентные решения, где AI анализирует код, понимает контекст и действует в IDE или терминале.

Roo Code — один из таких инструментов, работающий прямо в VS Code. Aider — его конкурент, но работающий через CLI. В этом посте я изучаю Roo, а про Aider расскажу позже.

Как работает Roo?

Roo предлагает три режима работы:

Architect 🏗️ — анализирует код, но редактирует только Markdown. Хорош для написания документации, аналитики и подготовки плана для кодинга
Code 🛠️ — полный доступ: читает, пишет, запускает команды. Если оставить без присмотра, может разнести весь проект.
Ask ❓ — просто отвечает на вопросы по коду. Безопасный, и очень полезный режим для анализа существующего кода

Проблема: Roo иногда перескакивает из Architect в Code потому, что так решил, так что если не следить — он внезапно начнёт менять файлы, хотя ты просто хотел, чтобы он что-то объяснил.

Выбор LLM: критичный момент

Roo сам по себе не думает, ему нужна LLM, и её выбор сильно влияет на результат. Я пробовал разные модели:

GPT-4o-mini, DeepSeek-R1 — дешёвые, но могут испортить код или зациклиться.
O1-mini, O3-mini — медленнее, но умнее.
Claude 3.5 Sonnet — отлично справляется, но дорогой.
Gemini 1.5/2.0 (через VPN) — бесплатный, но не всегда умный.

Реальный кейс: я попросил Roo написать тесты для одного модуля, и Claude 3.5 справился отлично... за 600 рублей. Потом я попросил Roo покрыть тестами мою библиотеку из 20 модулей. Первый запуск с O1-mini — минус 500 рублей на 5 модулей. Переключился на GPT-4o-mini — ещё 7 модулей.

Вывод: неправильный выбор LLM = моментальный слив денег.

Где Roo реально хорош?

Несмотря на косяки, есть сценарии, где он действительно полезен:

Генерация тестов. При грамотном промпте Roo пишет тесты, выполняет их, проверяет покрытие.
Memory Bank (расскажу подробнее позже).
Использование как суперзаряженный Windsurf.

Я пробовал Roo как аналог Windsurf или Cursor — решений, которые читают файлы и помогают с анализом кода. И в таких сценариях он реально удобен:

Найти баги в коде.
Объяснить, как связаны части проекта.
Рефакторинг и написание тестов.
Разбор кода, написанного другими разработчиками.

Но вот главный вопрос: почему я должен платить за Roo, если Windsurf и Cursor дают безлимит?

Roo vs. Windsurf vs. Cursor: кто кого?

Сначала я думал, что главное отличие Roo — это агентность, но оказалось, что Windsurf и Cursor тоже могут работать как агенты.

Windsurf — максимально автоматизирован: сам индексирует код, выполняет команды, чат по умолчанию работает в агентном режиме.
Cursor — даёт больше контроля: ты сам выбираешь файлы, сам подтверждаешь изменения.
Roo — требует оплаты за API, но даёт гибкость в настройке и управлении.

Так что разница не в агентности, а в степени автоматизации и контроле.

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

Где Roo фейлится (и как не сливать деньги впустую)

Он неспешный. Если задача сложная, он может крутить код часами без результата.
Нет лимита по токенам. Агент может зациклиться и сжечь весь баланс.
Не умеет стартовать проекты. Вместо npm create vite он пишет package.json вручную.
Как я слил деньги на автоаппруве? Я включил автоаппрув и ушёл, вернулся — куча токенов улетела в никуда.

Вывод: за Roo нужен глаз да глаз.

Как работать с Roo и не разориться?

Выбирать LLM с умом.
Не ставить автоаппрув.
Следить, не зациклился ли агент.
Использовать Gemini для бесплатных тестов.

Стоит ли пробовать Roo?

Да, но с оговорками. Если не контролировать, он сожрёт деньги впустую. Если включаться в процесс, можно получить неплохой результат.

Но зачем использовать Roo, если есть Windsurf и Cursor? Пока не очевидно. Судя по тому, что я вижу в сети, можно добиться от Roo хороших результатов, но для этого нужно применять Memory Bank, .clinerules, stdlib и другие продвинутые техники.

Я пока не тестировал эти методы, но собираюсь попробовать и рассказать, что из этого вышло.

Если интересно узнавать дальше со мной, подписывайтесь на мой телеграм-канал — https://t.me/sqr_dev_moments. 🚀

P.S. Не бейте сильно за оформление - я пока формирую стиль

🚀 Как сделать дебаг-логи понятными, полезными и легко читаемыми

Nubami SQReder — Sun, 16 Feb 2025 10:33:27 +0000

Отладка через логгирование — это классика. Независимо от уровня опыта, почти каждый разработчик в какой-то момент пишет console.log("здесь"), чтобы понять, что происходит в коде.

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

🔍 Основные проблемы стандартного логирования:
1️⃣ Логи трудно сканировать глазами, всё сливается в монотонный текст.

2️⃣ Поиск по console.log помогает, но без контекста всё равно сложно.

3️⃣ Простые теги ([INFO], [DEBUG]) не спасают — их тоже надо читать.

👉 Как сделать дебаг-логи понятными? Использовать цвета, структуру и эмоджи.

❌ Как обычно пишут логи (и почему это боль)

🔹 1. Логирование цифрами (чтобы просто отслеживать последовательность)

console.log(111);
console.log(222);
console.log(333);

🔴 Минус: пока вспомнишь, что означает 222, уже забудешь, зачем писал 111.

🔹 2. «Эмоциональные» логи (чтобы проще искать)

console.log("WTF, почему оно null?");

🔴 Минус: легко забыть удалить перед коммитом. Дальше объясняй тимлиду, почему в логах FATAL ERROR: oh shit.

🔹 3. Логирование переменной без выделения маркера

console.log(userData, "marker");

🔴 Минус: если логов много, сложно быстро найти этот конкретный.

✅ Как улучшить логи: добавляем визуальные маркеры

Наш мозг быстрее воспринимает цвет и иконки, чем текст. Решение — использовать эмоджи в логах.

🔹 Пример моих любимых эмоджи для логов:

🐊 (крокодил) — хорошо видно, радует глаз.
🐓 (петушок) — если нужно вывести две точки отладки.
💣 (бомба) — потенциальное место бага.
🧪 (колба) — тестовые данные, промежуточные вычисления.

👉 Пример лога с эмоджи:

console.log("🐊 Fetching user data...");
console.log("🧪 User ID:", userId);
console.log("💣 Unexpected response format!", response);

✅ Теперь важные места видно сразу, не нужно читать весь текст.

🤖 Как AI помогает логировать лучше

Писать такие логи вручную — это долго.

Поэтому я использую AI для генерации детализированных логов.

💡 Команда, которая упрощает жизнь:

add detailed debug logs with emoji. use console.group where applicable

Что делает AI:

✔ Добавляет осмысленные логи, а не просто console.log("here").

✔ Структурирует вывод через console.group → можно сворачивать и разворачивать группы логов в DevTools.

✔ Логирует промежуточные состояния, а не только финальный результат.

📌 Пример: ДО и ПОСЛЕ AI

❌ До (нет логов, максимально лаконичный код)

export const flow: FlowFn = (...fns: Array<PipeFunction<unknown, unknown>>): PipeFunction<unknown, unknown> => {
    return (value) => fns.reduce((acc, fn) => fn(acc), value);
};

✅ После (логика + эмоджи + `console.group`)

export const flow: FlowFn = (...fns: Array<PipeFunction<unknown, unknown>>): PipeFunction<unknown, unknown> => {
    console.group('🌊 Flow Function');
    console.log('📥 Received functions:', fns.length);

    return (value) => {
        console.group('🔄 Flow Execution');
        console.log('🚀 Initial value:', value);

        const result = fns.reduce((acc, fn, index) => {
            console.log(`🔹 Step ${index + 1}:`);
            console.log('  ⮕ Input:', acc);
            const output = fn(acc);
            console.log('  ⬅ Output:', output);
            return output;
        }, value);

        console.log('🏁 Final result:', result);
        console.groupEnd();
        console.groupEnd();
        return result;
    };
};

🔥 Теперь:

Логи сгруппированы, их легко свернуть в DevTools.
Важные точки отмечены эмоджи, и их сразу видно.
Легче найти ошибку, потому что console.group структурирует вывод.

📌 Где уместны такие логи, а где — нет?

✅ Подходят для отладки (debug-режим)

Когда нужно быстро находить ключевые моменты в логах.
Если логов много, и нужен удобный способ фильтрации.

🚫 Не подходят для продакшн-логов

В боевых логах важна строгость формата.
Автоматические системы (типа Logstash, ELK) могут не поддерживать эмоджи.
Логи должны читаться и без визуальных элементов.

👉 Решение:

Debug-режим → используем эмоджи и console.group.
Продакшн → строгие info/warn/error логи без визуального шума.

🚀 Вывод: как сделать логи полезными?

✔ Использовать эмоджи → цветные метки помогают быстро находить нужные места.

✔ Группировать через console.group → удобнее анализировать потоки данных.

✔ Автоматизировать с AI → AI помогает расставить логи там, где они действительно полезны.

🔥 Попробуйте! А какие эмоджи вы бы использовали в своих логах? 😎

🚀 Если тебе тоже хочется глубже понять, как AI может помочь в разработке – подписывайся, разбираться будем вместе! 💻 https://t.me/sqr_dev_moments

DEV Community: Nubami SQReder

Either-like Monads to automate Feature Toggles

Первый заход

Боремся с бойлерплейтом

Устраняем неочевидности

Управляемся с типами на выходе: знакомимся с монадами

Что такое монада простыми словами?

Either - выглядит очень интересно!

Chaining

Промежуточный итог

Полная реализация

Практическое применение

Пример 1: Переключение между реализациями логгера

Пример 2: Переключение компонентов UI

Пример 3: Настройка через параметры окружения

Преимущества подхода

Недостатки подхода

Заключение

Я наконец понял, что такое монады (и ты сейчас тоже поймёшь)

🧩 Что такое монада по-простому?

🔍 Maybe — когда значение может отсутствовать

⚔️ Either — когда нужно явно разделить успех и ошибку

⏱️ Promise — это почти монада, и ты её уже знаешь

💡 Что мне дали монады в реальной работе?

🌟 Монады на пальцах

Roo Memory Bank prompt

🧠 Memory Bank in the nutshell

Cline

Roo

⚡ Небольшой лайфхак

🔗 Links

Roo Code: AI-разработчик в твоём VSCode (но за твои деньги)

Агентные инструменты: немного контекста

Как работает Roo?

Выбор LLM: критичный момент

Где Roo реально хорош?

Roo vs. Windsurf vs. Cursor: кто кого?

Где Roo фейлится (и как не сливать деньги впустую)

Как работать с Roo и не разориться?

Стоит ли пробовать Roo?

🚀 Как сделать дебаг-логи понятными, полезными и легко читаемыми

❌ Как обычно пишут логи (и почему это боль)

🔹 1. Логирование цифрами (чтобы просто отслеживать последовательность)

🔹 2. «Эмоциональные» логи (чтобы проще искать)

🔹 3. Логирование переменной без выделения маркера

✅ Как улучшить логи: добавляем визуальные маркеры

🤖 Как AI помогает логировать лучше

📌 Пример: ДО и ПОСЛЕ AI

❌ До (нет логов, максимально лаконичный код)

✅ После (логика + эмоджи + console.group)

📌 Где уместны такие логи, а где — нет?

🚀 Вывод: как сделать логи полезными?

✅ После (логика + эмоджи + `console.group`)