Это тех. директор включился в наш репозиторий, не такой он и новый, дольше меня в комманде.

Предложи свой вариант, но делай как решит директор. А как лучше на месте виднее же. Думаешь все переписывали stepbystep на дебагер и обратно

Привет! Вопрос по архитектуре и дизайну.

Есть long running worker, который выполняет сложную логику, который очень сложно было дебаггить.

Теперь, я в своё время добавил то, что он собирает статистику и сделал его дизайн полностью step-by-step, что он мог останавливаться (по запросу), что его можно было интроспектировать и говорить, работай дальше, при том основную часть запросов я там научил складывать в queue и не держать в message queue.

Пришёл другой разработчик и хочет возможность процесса работать step-by-step убрать и добавить debugger модуль, а основной процесс умеет только делать - attach_debugger, detach_debugger и добавляет в одном месте возможность обратиться к дебаггеру и блокируется и уже другой процесс отвечает за то, продолжить или остановиться и что делать с процессом.

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

Что считаете? Как по Вашему опыту лучше? Заранее благодарю за любое мнение.

Мой step-by-step можно дальше переделать в траверсинг по времени, вперёд назад.

Т.е. step-by-step - в данном случае архитектурный паттерн, который можно по-разному использовать, а его debugger - это просто дебаггер.

Пришло — обработал сразу.

сложить в queue это значит оставить респонсивнес процесса и самому контролировать когда начать дропать данные, что прилетают на вход если не успеваешь обработать

sys:get_state вам для дебага не хватает вкупе с трассировкой?

Когда не успеваешь обработать надо рефакторить код а не дропать данные