Иногда сложность оправдана

Чаще нет

В рамках нашей команды для защиты от непонятного кода коллег есть обязательный Code Review)

Это к вопросу "разбитых окон". Ты когда убеждаешь себе что что-то норма этого что-то будет становиться больше

тут вопрос как распознать такую ситуацию, что пора вкладывать ресурсы в настройку отладчика

все просто - ты не понимаешь, что происходит. а надо понять, и побыстрее желательно)

и если ты разобрался и ничего не сделал что бы потом было проще - проблема останется. Об этом и речь выше.

Мои поинт в том что использование дебагера это не норма. Это симптом проблем. Значит ли это что дебагером не надо пользоваться - нет не значит. Это лишь значит что должно быть осознание что "возможно если часто пользуюсь дебагером значит я не понимаю как это работает и возможно стоит инвестировать время если буду дебажить этот кусок третий раз".

кстати. а xdebug+шторм уже позволяют нормально отлаживать одновременно 2+ взаимодействующих сервиса (проекта в терминах шторма)? Вот типа поставил брейк на $guzzle->get(“api/order/$id”) в первом, он сработал,нажал step over и срабатывает брейк на контроллере второго сервиса c переключением фокуса? Лет 5 назад с этим проблемы были

рефакторинг классная штука, и хорошо, когда дают им заниматься

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

очень редко когда "не дают заниматься рефакторингом". Либо это проблемы процессов/планирования либо проблемы разработчиков (когда паника и надо все переписать). Рефакторинг не должен быть чем-то что "вот я 2 недели писал и теперь буду неделю рефакторить" тогда вопросов "как найти время" быть не должно

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

словом "рефакторинг" и "рерайт" это разные вещи и не надо использовать эти термины взаимозаменяемо

в норм проектах обычно не гонят с этим, это да

это ж бред. каким бы понятным код не был, лажа будет где-то в данных, в фреймворках и библиотеках

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

дебаггер - это экономия времени. если от него отказываться... то даже не знаю

я могу сказать так. Даже если менеджмент явно говорит что "20% времени закладывайте на тех долг" этого недостаточно что бы тех долгом занимались. Это такой же процесс планирования анализа и приоритизации что и фичи.

Так же если менеджмент не говорит явно "20% на рефакторинг" он обычно у тебя спрашивает сколько займет времени и это твоя проблема что ты не закладываешь риски и прочее.

Словом все это отговорки разработчиков

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

я про цепочки сервисов независимых, один на example.com и он стучится на второй на example.net. Надо посмотреть что первый отправляет и что второй получает. Для щторма это два разных проекта на двух разных серверах/контейнерах/виртуалках

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