Обновить

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

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

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

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

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

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

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, а не просто хранилище строк.

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

Публикации