Хочу поделиться, как страдал фигней в переывах от основной деятельности или маленькая история про то, как я хотел сделать «бот по wiki». Cпросил про наш проект, получил короткий ответ и пошёл дальше работать.

Есть Confluence с описанием продукта (спецификации, docs), есть Python, внутренняя LLM, ну и кривые руки + немного времени. И да я не пайтон разработчик, мой максимум всякая автоматизация, поэтому смело пинайте мой код, я на нем не женат. Цель - чтобы бот мог отвечать на «объясни XXX».

Идея вообще простая

Берём Confluence, берем текст из нужных нам статей и индексируем в квадрант ([qdrant](https://qdrant.tech/)).

Понятно, что всякие регламенты от QA и лишние шумовые документы не хочется засовывать в систему - мозг и так забит, зачем бота травить этим же? Поэтому входной параметр у нас -страница, от которой рекурсивно идём вниз по дереву страниц и собираем только релевантный контент.

Иногда мы не можем локально поймать баг, приложение слишком сложно в конфигурации или просто кривые руки и QA может воспроизвести в 2 клика, в отличии от нас.

Пусть наши стенды это или docker или Kubernetes кластеры.

*иногда хочется уйти от управляемых будней

Корутины — это функции, которые могут приостанавливать своё выполнение и возобновлять его позже, сохраняя своё состояние между вызовами. Это позволяет выполнять несколько задач одновременно без необходимости создания отдельных потоков или процессов.

Современное приложение на Java с использованием Spring Boot, включающее множество клиентов (веб, десктоп, мобильные), может столкнуться с проблемами в тестировании по мере его роста. Даже при хорошем покрытии тестами (80%+), увеличение объема интеграционных и приемочных тестов может привести к значительным задержкам в процессе разработки. Тесты могут занимать до 24 часов для выполнения, что снижает эффективность и увеличивает риск багов в продакшене. Не знаю кто сказал, но вполне четко описывает процесс разработки

Что делать

... кроме написания резюме в поисках более интересно проекта?

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

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

Ускорить тестировщика, без незаконных препаратов, мы не можем, как и сделать UI который будет работать без задержек, на скорости api (но можно постараться, но дорого...).

Основные шаги для решения:

Рассмотрим очередной популярный подход к проектированию систем для управления и координации выполнения бизнес-задач или процессов на основе событий. В общем случае это микс Хореографии и Оркестрации. Рассмотрим их подробнее.