Обновить

Я заколебался искать запятую в коде бота — и написал библиотеку, чтобы диалоги жили в YAML

Уровень сложностиСредний
Время на прочтение12 мин
Охват и читатели9.2K
Всего голосов 3: ↑3 и ↓0+3
Комментарии5

Комментарии 5

Как один из тех ребят, что пилят боты(с), напишу про своё:)

Вся описанная в статье проблема изначально была в архитектуре.

У меня этих проблем сейчас нет, я итеративно пришёл к решениям:

1. Централизованные константы
2. Персонажи в конфиге
3. Утилиты для клавиатур
4. Очередь с rate limiting
5. Модульная архитектура
6. Конвенции задокументированы:
- Константы в стиле SCREAMING_SNAKE_CASE
- Barrel-файлы (index.js) для чистых импортов
- Запрет циклических зависимостей
- Обязательные try-catch и таймауты

Также в коде JSDoc комментарии, zod-схемы.
Тесты - vitest, ESLint, coverage, watch mode.
Документация - ARCHITECTURE.md, MODULES.md, DECISIONS.md, причём, ARCHITECTURE.md это роутер на более мелкие файлы по архитектуре в отдельной папке, это чтобы не вставлять все сотни строк в промт каждый раз при использовании нейросетей.

Для разглядывания красоты кода и для установления всех зависимостей -  Graphify, рекомендую :)

У меня бот на JavaScript, разнесён на Cloudflare Workers + Yandex Cloud, и без вышеприведённых решений я бы, наверное, давно сошёл с ума:)

Отличная идея — и три года на одном боте точно дают право на такую библиотеку. Кстати, следующий уровень к этому подходу: хранить в YAML не только тексты, но и переходы между состояниями (state → next_state + условие). Тогда при росте бота «где находится запятая» и «откуда пользователь попадает в этот экран» живут в одном месте — и это уже полноценный dialog manager, а не просто хранилище строк.

Если говорить про dialog manager, то почему тогда не aiogram-dialog как раз?

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

Ну во-первых, он упоминался в посте и какое-то ощутимое количество юзеров всё таки есть. Во-вторых, 40 issue, из которых большая часть - идеи по развитию - это не очень большое число. В третьих, проекту несколько лет, он давно прошел стадию активного наращивания фич, че там коммитить каждый день? В четвертых, кажется для кейса комментатора выше как раз неплохо подошло бы

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации