Весь мой проект состоит из таких кусков - где тут

место отладчику?

Внешние сервисы, база. Код может работать правильно и без ошибок, контракт верен, тупо данные неправильные

если это в принципе возможно - код в любом случае надо снабжать валидатором. где тут место отладчику?

Часто надо понять, это внешний сервис не те данные отдаёт, или ты в бизнес-логике облажался

да забей, этот спор не окончится каждый останется при своем мнении

бизнес-логику в любом случае надо покрывать тестами если же у вас тесты проходят, а в реальности лажа - надо наращивать количество тестов по-любому, с дебагером, или без и где тут место дебагеру

А кто сказал, что тот неожиданный json не валидный? Вот ждал ты там где-то 10 (и на этом значении у тебя логика построена), а по факту там 11

Вот есть у меня сервис, который манипулирует только id складов. Он рассчитывает маршруты, например. То есть в базе лежат маршруты из айдишек. На ui склады выводятся с названием. Названия складов я получаю из внешнего сервиса. И этот внешний сервис ответил мне, что склад 1234567 называется "Тверь". А в реальности это не тверь. Как мне помогут тут тесты?

Интеграционные тесты и мониторинг должны поймать эту проблему раньше разработчика

Как? Кто-то накосячил в БД стороннего сервиса. Контракты соблюдены. Бизнес-логика отрабатывает правильно. Проблема только в выводе данных на UI

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

Дело не в архитектуре. Это стандартный пример bff-сервиса. Есть несколько микросервисов, которые манипулируют только id (заказы, маршруты, категории и прочее). Перед выводом на UI все эти данные обогащаются через сторонние сервисы в bff-сервисе. Никто не будет менять архитектуру из-за гошников, которые свято верят в ненужность дебагера

а как вам дебагер поможет выловить неконсистентность в справочных данных? никак, правда?

Никак. Можно пытаться бороться с этим через типы

Он даст мне уверенность в том, что проблема в неправильных данных стороннего сервиса, а не в логике моего приложения. Да, он поможет мне это сделать уже после момента, когда эта бага случилась. Но тесты не помогут ни до, ни после

"Тверь" и "Москва" - это ж один тип

Все так. На самом деле этот подход в корне неверный. Надо ни название населённых пунктов использовать, а прямоугольники/окружности на поверхности. Потому что Москва большая и складов там может быть несколько.

и все равно справочник может оказаться неконсистентен

Логирование запросов/ответов стороннего сервиса на изи решает эту проблему.

Это да. Ну ты тоже каждый кузнец своему счастью ))

Вы серьёзно? Есть реальные склады, у них есть названия и id. В ui выводятся именно склады. Мне нужно прийти к гендиректору и сказать, что ему запрещено давать названия складам, потому что я не хочу использовать дебагер?

У меня 50к рпс. Мне каждый запрос логировать? Если да, то как потом искать нужную запись?

А как в дебагере 50к рпс просматривать?

Локально запускаешь сервис и дёргаешь ручку с нужными данными. Всё

если вы поняли где баг, то найти нужный запрос не составит труда

Блин, а мне никто не даст из локальной сети дёрнуть эндпоинт с прод данными

Какими данными? :) вам же их надо где то взять))

Я же говорил, что мы изначально исправляем багу на фронте. Там можно взять данные через f12

Вообще, если у компании такой бардак с данными в собственном сервисе - наверное, не стоит там работать.

Кажется, вы что-то не поняли

Кстати доля правды в этом есть. Я бывало увольнялся из-за бардака

Тогда вообще не понимаю, где тут нужен дебагер. Получается у вас сломан контракт между фронтом и беком.

Это немного и вполне можно логгировать.

Откуда появляется знание что 1234567 - это не "Тверь"?