18 августа 2010 г.

Каменный век пора бы оставить

Еще когда я только изучал программирование и игрался с Borland Pascal 7.0 я научился пользоваться встроенным дебаггером. Гениальная фича, позволяющая увидеть значение любой переменной во время выполнения, остановить выполнение программы в любой удобной точке и многое другое.
Но суть не в паскале. Суть в том что PHP это все тоже есть, а народ с завидной упертостью тратит часы на var_dump() и print_r();die(); вместо того что бы потратить пять минут на настройку xdebug и любимого ide (netbeans или PDT|Zend Studio) и наслаждаться процессом дебагинга.
Особенно удивляют люди который "вардампят" внутри Zend Studio. За что платили, то? Аналогично и с Zend Framework, вед Zend_Debug + Zend_Log просто не оставляют шансов var_dump.

В чем причина?

Я думаю в том-самом "легком старте" PHP. Люди научившись находить проблемы одним способом считают что лучше быть не может и останавливаются на этом. Еще народ не хочет учится, хотя для программиста этот процесс должен быть перманентным. Мало внимания уделяют этому и книги, в тоже время вовсю прославляя var_dump.

Что делать?

Лично я решил в ближайшее время написать мини-статью о "правильном" environment разработчика и основе дебагинга, а также в следующих своих записях использовать debug скрины (правда не знаю как, скорее в виде скриншотов) кода вместо простого var_dump и отображения результатов.

2 комментария:

Anatoli Sakhnik комментирует...

Може трохи не до речі, але у своїй практиці я перейшов у протилежному напрямку. Якщо колись без налагоджувача нічого не запускалося, то тепер я радше буду друкувати повідомлення у системний журнал, і вивчати проблему пост-фактум. GDB тепер потрібний, тільки якщо програма отримує неприємний сигнал SIGSEGV.

Журналювання популярне (і недаремно) у багатопоточних і асинхронних системах: ядро, GNOME, прикладні сервери тощо.

valeriy комментирует...

Да, логирование очень позитивная практика. Я упоминал Zend_Log, который как раз предназначен для таких вещей. Основная проблема заключается в другом:
1. Использование var_dump, print_r выводит значение переменных в тот-же поток что и результат программы. Со всеми вытекающими. Я не думаю что в С++ используется print для дебагинга.
2. Многие не знают о возможностях Xdebug, а на этапе "пуско-наладочных" работ этот способ бывает даже более продуктивен чем журналирование, например когда надо построчно (по функциям) определить цепочку запуска и место ошибки без закидывания var_dump в десятке файлов с выводами типа "stage 1", "stage n"...

В любом случае нужен организованный дебаг, коим var_dump никак не является

Поиск