> ## Content Index
> Fetch the complete content index at: https://www.rozhkov.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# Пет-проект для портфолио миддла и сеньера
- URL: https://www.rozhkov.me/pet-project-for-middle-senior/
- Published: 2020-11-25T07:00:00.000Z
- Updated: 2020-11-25T07:00:00.000Z
- Author: Vova Rozhkov
- Tags: робота, кар'єра

Какие могут быть варианты развития маленького чат-бота? В исходном тексте я описал инфраструктурные вещи—усложнение всего, кроме логики бота. Что делать, если хочется программировать, а не фуллстечить, девопсить и разбираться с кубернетесами?

Бот работает только в телеграме. Скорее всего, там отсутствует прослойка логики обработки диалогов. Что, если понадобится добавить еще один мессенджер? Для этого нужно добавлять абстракции—диалог, кнопка, событие от мессенджера, контекст пользователя. Выделение такого слоя и поддержка других мессенджеров и будет задачей для миддла.

Ок, сделали абстрактное API, модули под телеграм и вайбер, что дальше? Бот поддерживает только вопрос-ответ, и не запоминает предыдущие выборы пользователя. Это ок для квиз-бота, но не ок для чего-то более сложного. Например, мы хотим спросить пользователя, тесты какого уровня сложности он хочет проходить. Можно зашить эту логику в саму программу, но тогда при добавлении еще одного варианта выбора нам придется пересобирать проект. А даже если мы это предусмотрели и значения будем брать из базы, то на добавлении еще одного шага, например спросить емейл или фидбек о тесте, точно придется дописывать код.

Это никуда не годится, нужно делать абстракцию для графа диалога. Такая функциональность крайне распространена в энтерпрайз-проектах—всем нужно описывать бизнес-процессы и иметь возможность их гибко конфигурировать руками нетехнических людей. Самый простой способ реализации—это представление диалога как [конечного автомата](https://en.wikipedia.org/wiki/Finite-state%5Fmachine) или цепочки "[workflow](https://en.wikipedia.org/wiki/Workflow%5Fengine)". На состояниях мы будем рисовать пользователю сообщение, а переходы вычислять по его ответам. В автомате нужно предусмотреть использование [скриптового языка](https://docs.spring.io/spring-integration/docs/5.3.0.RELEASE/reference/html/spel.html), чтобы, например, обращаться к пользователю по имени: `"привет, ${username}"`.

Дальше нужно сериализовать структуру автомата и давать возможность редактировать её другим людям. Это задача со звёздочкой, потому что конфигуратор потребует владения фронтенд-скиллами. Как может выглядеть такой продукт, можно посмотреть на примере [BotPress](https://botpress.com/).

На моей первой работе у нас было две реализации workflow и они очень активно использовались на всех проектах—потому что вместо задействования дорогих программистов, можно было наконфигурить формы и переходы между ними с помощью более дешевых системных инженеров. На второй работе тоже сделали кастомное решение для конфигурации форм и бизнес-процессов. Многие компании делают похожие продукты, заточенные под разные бизнесы, из известных это [Corezoid](https://www.corezoid.com/) на котором раньше работал ПриватБанк.

Реализация всего этого—хорошая задача для сеньера.

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