Comments 24
Судя по статье, вам нужно просто научиться пользоваться отладчиком )))
Если ее прочитать, то там как раз сказано, что отладчики уже не помогли. Ошибка есть но где именно не понятно. Непонятно куда лезть отладчиком.
Если вы не знаете, где ошибка - тогда ее нет.
Если она есть, то есть момент, где ожидание разошлось с действительность.
Определяем условия воспроизведения ошибки. Иногда может помочь логгирование.
В общем, я не понимаю, зачем изучать код, когда его можно просто прогнать на данных, которые приводят к ошибке. Всегда можно. Иногда это не совсем просто, иногда нужно логировать, вытаскивать данные, делать определенную подготовку, но это всегда проще, чем анализ кода и 100% гарантирует результат.
Анализ кода полезен, но только на первом этапе ("а дай-ка я код гляну для начала...").
Можете привести пример, когда ошибку нельзя воспроизвести и нужно до умопомрачения анализировать код?
Можете привести пример, когда ошибку нельзя воспроизвести и нужно до умопомрачения анализировать код?
Например, такая ситуация. Есть программа, которая забирает письма из почтового ящика и потом что-то с ними делает. Клиент жалуется, что иногда она портит имена аттачей. Чаще всего не портит, но иногда — портит. Предсказать, будет ли имя испорчено, нельзя. В прошлой версии всё было нормально.
Если взять ошибочные письма, отправить их себе на нашем почтовике и потом локально забрать программой на машине разработчика, то имена аттачей никогда не портятся.
Моё мнение: надо проанализировать код, посмотреть, что в нём менялось по сравнению с прошлой версией, и уже там искать ошибку.
"Человек сидит, смотрит на экран, проверяет все построчно. Разбивает текст на отдельные части и пытается таким образом изолировать ошибку. Но все тщетно. Ошибка не находится." Это он все делает обычно в отладчике. Я не думал что это надо пояснять.
Зачем текст разбивать на части? Зачем построчно проверять?
Просто идешь по шагам и проверяешь данные. На каком шаге разошлись с ожиданиями - там и ошибка. Это азы.
В общем, какая-то ерунда у вас происходит...
А если в дебаге все работает, а в релизе нет? )) Это же не однопоточные приложения, а иногда даже не один исполняемый модуль.
Ну бывает в протоколах частично битые сообщения. Или как в примере про интербейз. Ошибки во вторичных индексах есть но только при некоторых размерах записей и не всех а только некоторых.
Или мультипоточная обработка сообщений. Плавающая ошибка.
Есть много не линейных приложений. Там даже в отладчике иногда смысла нет.
Обычный "генеральский" эффект.
В пору сисадминства было дело с матричным принтером, бумагу он жевал. Я прихожу, говорю, показывайте. Он печатает исправно. Ухожу - опять жуёт. А всё оттого, что бумагу небрежно клали. А при мне - ровнёхонько, как и надо было.
Может и так. У меня точно такой же опыт. Когда я был сисадмином то при мне всегда все работало.
У меня - не всё и не всегда. Видимо, я какой-то неправильный сисадмин был.))
Я думаю, что когда человек от безысходности обращается к коллеге с просьбой о помощи, возникают отношения "master - slave", где мастером-генералом выступает коллега.
"всегда и все" это не в математическом смысле а в философском. Приходишь к исполнителю, а он не может повторить ситуацию, когда у него что-то не работало. Очень часто. Чаще, чем реально есть проблема.
Да в том то и дело что все ближе к тому, что второй человек размывает фокус. Смотрит на все со своей стороны. Неожиданной для автора кода.
На самом деле конечно не генеральский эффект. Не важно генерал будет или солдат тыкать в экран и соучаствовать. Просто коллега
Это же применение "метода утёнка" по сути. Когда не понимаешь или не разбираешься в какой-то теме, надо пытаться объяснить (или представлять, как ты объясняешь) её кому-нибудь, коллеге, другу, утёнку, который стоит рядом с монитором.
Но это не "не понимаешь". Это профи застрял. Интересны подробности. "Тестируемый ставит на рабочем столе игрушечного утёнка (резиновая уточка — это условность, на практике можно использовать любой предмет, "
Так не пробовали. Но работающий точно вариант - это коллега, задающий наводящие вопросы и тыкающий в код. Рассуждения самого застрявшего вслух или про себя ничего как раз и не решали.
Собственно, автор открыл метод уточки - сажаем резиновую уточку рядом с кодом и рассказываем ей, как он работает. В какой-то момент случается щелчок и смотрящий в код понимает где мог случиться косяк.
В общем это работает в ошибками
как правило простыми., поэтому их находить трудно самому. Потому что изначально они в голову не приходят. Ну например, у вас возникает ошибка при открытии датасета, когда он пустой. Ошибка конвертации значения поля бд в таблице. Сразу приходит на ум лезть в бд и проверять запрос. Ничего не находится. Всё нормально. В отладчике ошибка возникает где-то в глубине системных библиотек, так что это ничего не даёт для прояснения причины. Начинаешь делать программные костыли сначала в запросе, потом на клиенте. Ошибка вроде исчезает. Но в каких то ситуациях опять появляется. Да, думаешь как её найти непонятно пока. Но через пару дней вдруг вспоминаешь, что в таблице клиента есть подсветка строк, которая работает по данным бд. Опаньки, об ней почти забыл. Вставляешь проверку на еof и вуаля, ошибки больше нет. Просто надо было сразу сесть и не дергаясь написать возможные причины такой ошибки от простого к сложному. Но человек так устроен, что идёт наоборот, иот сложного к простому. А когда ты рассказываешь свою проблему партнёру, как раз работает эта схема, от простого и ошибка сразу находится. По моему опыту в SQL ошибки находятся проще, даже в довольно о сложных хранимых процедурах с обработкой данных. Как правило достаточно запускать в отладчике процедуру и рефакторить код.
Поиск ошибок в программах. Психологический аспект. Вопрос без ответа