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

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