Комментарии 3
По моему опыту, процесс выглядит так:
надо убедиться, что проблема существует. Каждый сталкивался с поиском отсутствующей черной кошки, потому что клиент не туда посмотрел, использовал не ту версию, ошибка на самом деле возникает в другом компоненте и т.п. И тут очень важно вопроизвести проблему (это пригодится потом, чтобы убедиться, что проблема исправлена)
если есть очевидная версия, то проверяем ее (то, что автор назвал "научным подходом", с гипотезами и экспериментами)
очевидная версия не подтвердилась ("спасибо, наука, за попытку, дальше инженеры сами"), берем инструменты (valgrind, дебаггер и т.п.) и анализируем
находим, удивляемся, как это вообще могло работать и что за олень (как правило сам) это написал
исправляем, пытаемся воспроизвести, хорошо бы еще добавить unit test для этой ситуации, ну на случай регрессов
И еще - статический анализа кода надо делать не тогда, когда ошибка вылезла, а всегда, в идеале - в процессе сборки.
Чтобы экономить время и нервы при отладке - нужен хороший отладчик :-)
Отладка - долгий и мучительный процесс осознания программистом того факта, что программа работает в точности, как он написал.
Как экономить нервы и время при отладке кода