Комментарии 15
Все программисты делятся на две группы: те, кто пользуются дебаггерами и те, кто считает дебаггеры уделом пораженческого подхода к разработке…
Если мне хочется воспользоваться дебаггером для своего кода, значит он отстойный и я проиграл в этом раунде, надо переделывать. Это еще можно понять, если речь про системные языки программирования с утечками памяти, типа C/asm или отладкой сторонних либ, но PHP… Вам в помощь сила декомпозиции и юнит-тесты, если не помогло, добавьте логов и трейсинг типа OTLP.
Конструктивно: формат шпаргалки неудобен для читателя. Если для себя писали, могли бы и на гитхабе документик в маркдауне создать. Здесь - для людей.
Дебаггер - очень удобный инструмент для работы в первую очередь с чужим кодом. В режиме "чукча не читатель" он, конечно, особо ни к чему...
Спасибо за отзыв , поправлю формат) не ожидал, что выложат с первого раза
Как то очень категорично. А чем дебаг в условном go или java отличается от дебага в php?
Ничем, по сути, ни там ни сям нет фокусов с указателями и есть понятные стектрейсы.
Тогда я не понимаю почему плохо пользоваться дебаггером в php
А я не про php, а про дебаггер, в целом. Это мое мнение, но если Вам нужен дебаггер для кода, для которого есть исходный код и тем более написан Вами, то Вы просто написали плохой код, в котором не смогли контролировать сложность, нет тестов и т.п.
Дебаггеры в низкоуровневых языках типа C/C++ могут помочь, если случайно происходит неверная работа с памятью, хотя тоже сомнительно. Пишите функции с разумной сложностью и тесты на них и никакие дебаггеры Вам не понадобятся.
Я правильно понимаю что код который вы пишите работает сразу же и без каких либо ошибок?
Я пишу много тестов :) как только они все работают - код рабочий.
А причины в том, что (а) я не настоящий программист, поэтому чувство уверенности у меня не очень высокое; (б) я настолько ленивый, что при изменении кода я хочу сразу понимать что сломалось и где, а не разгадывать детективные истории.
Ну и по этой же причине, я не очень люблю языки с динамической типизацией, хотя раньше много писал на Perl и Python. Сейчас, преимущественно на Rust и Python. На первом вся функциональность, на втором весь бокс-мувинг.
Вообще, у людей, которые TDD или нечто подобное практикуют, "рабочесть" кода определяется "рабочестью" юнит-тестов и интеграционных тестов. Если находится баг, я пишу на него тесты. Более того, с пришествием GitHub Copilot и код стало писать веселее и тесты для него.
Забавно, вспомнил свою статью 2018 года про это.
Тесты это классно, но иногда есть расхождения между тем как должно работать, и как на самом деле работает. В тестовой среде может не быть каких то данных, внешние системы заменяется моками, а баги могут быть плавающими и проявляться только под нагрузкой, при наличии увеличенного лага репликации базы данных, или например при параллельном выполнении нескольких потоков. Так же баги могут быть во внешних библиотеках или в самом фреймворке.
Поэтому я не понимаю вашу категоричность в этой фразе
Если мне хочется воспользоваться дебаггером для своего кода, значит он отстойный
А по поводу тестов, я правильно понимаю что вы после написания тестов пишите код сразу без багов и с первого же раза ваш код проходит написанные вами тесты?
Какая разница сразу он рабочий или не сразу? Когда он покрыт тестами и я доволен кодом, тогда он и идет в интеграцию. Дебаггер вот мне совершенно не нужен.
Пишите тесты на ситуацию с БД. Вам в описанном вам случае нужен не дебаггер, а трейсер и прочая телеметрия. Есть интеграционные тесты, есть chaosmonkey. Docker открыл дорогу к тестированию на любые фантазии.
Если сторонняя либа без исходников - это история грустная, но нефантомные баги локализуются и воспроизводятся и отправляются вендору и без дебага. Вам зачем знать отчего оно глючит?
Многопоточный код - это отдельная история и больше про квалификацию и опыт, а не отладку в дебаггере.
Я солидарен с вами в том, что тоже не использую дебаггер, так и не привык. Однако отмечу что ряд коллег ловко использует его как раз в тестах, чтоб понять почему же он не проходит. Так что дебаггер никак не противоречит хорошему покрытому тестами коду, это лишь дело вкуса.
Активно пользуюсь дебаггером и пишу тесты.
Но, к сожалению, опыт показывает, что в мире PHP такой подход не является общепринятым. Все ошибки отлавливаются, как правило, с помощью dd()/var_dump()
Гайд 2023 Xdebug в PHPSTORM + Virtual server + Docker для macOS с пробросом портов