Какие бывают способы отладки
Взято из сети
Взято из сети
Я не очень понимаю, зачем нужны километры логов. Я знаю людей, которые так делают и пишут в лог всё. Вот вообще всё. Но нахуй это надо - непонятно. У меня всегда как-то получалось очень быстро это решить, без простынь.
А вы, сударь, либо работаете в 1, ну может, в 2-3 программера в тесном кругу и спросить, какого хрена и что там делает этот кусок кода, написанный вот в этой жопе 17 месяцев назад не возникает проблем.
В то время, как в обычной российской (да и не только в РФ) it-компании кодеров гораздо больше, состав с годами сменяется и первоисточник давно не работает в фирме, а те кто есть, шугаются при виде этой химеры и лезут за святой водой в тумбочку.
Ну или 3 вариант: телепатия 80 уровня и абсолютная память.
Быстро локализуется проявление проблемы, а не причина. Например, у тебя опрашиваются 5 разных источников и потом по какой-то формуле считается результат. Возникло деление на ноль. Кто виноват? Какой-то источник вернул неправильные данные? Был неправильный запрос? Ответ неправильно распарсен? Ошибка в формуле? Или, что тоже бывает, все правильно, просто аналитики не предусмотрели такой кейс?
Так логгировать надо ошибку и потом по стеку разворачивать. Там и видно сразу все данные, откуда, куда и зачем.
Это геморно в плане количества кода, но в этом случае лог пишется исключительно по делу, а не на каждый чих.
Ну это как если бы тебе на баг-трекер приходили не ошибки, а вообще любые действия юзера.
Стек дает только понимание в каком месте возникла ошибка. Вот простой пример:
resp1 = source1.get(req1);
resp2 = source2.get(req2);
resp3 = source3.get(req3);
response = aggregateResponses(resp1, resp2, resp3);
processResponse(response);
Где-то в processResponses возникла ошибка. Даже если в момент возникновения ошибки залоггируется response, это никак не поможет понять, где конкретно проблема - в source1, source2, source3 или в aggregateResponses. Мы увидим только следствие, а не причину.
Если все локальные переменные в логе и стек тоже мы увидим
что ошибка в processResponse, и все данные, переданные в него, а также req1, req2, req3 и результаты ответов на эти запросы, так как всё это будет в логе, считай снимок памяти + breakpoint. Дальше изи.
Т.е. вы предлагаете каждое потенциально опасное место оборачивать в try... catch и логгировать все переменные? Что тогда с кодом будет?
Я реально не понимаю, что вы доказываете. Как вы хотите сделать так, чтобы ничего нигде не писалось, но в случае возникновения ошибки волшебным образом залоггировалось вся необходимая информация, которая позволит сразу понять, где проблема.
Вот другой пример:
resp = perform(resp);
sendToClient(resp);
В sendToClient произошла ошибка. Но ее причина - где-то в perform. Эта функция может включать в себя сложный функционал с вызовами других функций. Как стектрейс, пусть даже со всеми переменными, поможет вам понять, в чем именно проблема?
Если проблема вызвана в функции - тип ошибки и определит где искать в предыдущих вызовах. Если проблема воспроизводится - оборачивай, логируй и ищи.
У меня примерно раз в 3-4 недели, блок авторизации(достался в наследство, заменить никак) падает и терминалы рабочие на производстве виснут. Уже пятый год не понимаю, что это такое.
Можно я тебе в следующий раз напишу и ты поможешь?)
Ошибка может быть не явная, программа работает, а результат другой. Как пример - не корректный SQL-запрос внутри программы, с ошибочным фильтром.
а чтобы потом на вопрос клиента "какая сука вот тут стерла нолик и поставила двоечку" - можно было эту суку назвать.
Но это другое, это не отладка, а протоколирование действий пользователя. К отладке не имеет никакого отношения, хотя можно данные использовать.
Но это другое, это не отладка, а протоколирование действий пользователяНе правда. Когда клиент говорит, что у него что-то не работает, это может быть баг, а может быть ошибка пользователя. Оба этих сценария выглядят как багрепорт в твоей почте, в обоих случаях надо разбираться. Как ты без полного лога отличишь одно от другого?
Пользователь сделал Х, потом Y, потом Z. Получил в результате А, хотя по смыслу должен был получить В. Никаких явных ошибок нет, программа просто работает неправильно. Что делать?
Искать баг в алгоритме работы того блока где идёт работа с этими данными... или может либа какая юзаеться несколько неверно... Лодку мне!
Искать баг в алгоритме работы того блока где идёт работа с этими данными
Какой блок? Какой алгоритм? В обработке пользовательских сообщений участвуют сотни классов, сотни тысяч строк кода суммарно. И каждое сообщение проходит довольно долгий путь между запросом и ответом.
секас что тут сказать... но проблема тем не менее где в этих самых сотнях классов... и кстати что за громадный проект такой? CRM какая чтоль?
Зачем тогда по-твоему существуют уровни логов warning, info, debug, trace?
UPD: Лол, я нашёл человека, у которого я в игноре
IT-юмор
5.6K поста52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору