Третий метод отладки

[zHz00]

Есть два основных метода отладки:
1. Отладочная печать ("дедовский метод");
2. Интерактивная отладка.

В первом случае в программе в определённых местах добавляются команды, выводящие на экран (в файл) информацию о том, что происходит в программе, значения переменных и пр.
Во втором случае мы выполняем программу по строчкам. В нужных нам местах программа встаёт на паузу, а мы уже сами смотрим своими глазами, что там происходит.

Когда в институтах обучают программированию -- периодически "забывают" обучить студентов использованию интерактивной отладки -- и очень зря. Это очень нужная вещь. Не знаю, возможно полагают, что тема слишком простая, поэтому студенты освоят её самостоятельно?

Второй метод удобнее, но доступен не всегда. Иногда процессы, которые приходится программировать, должны разворачиваться с нормальной скоростью, то есть постановка на паузу всё рушит. Другой случай, когда интерактивная отладка недоступна -- ошибки в программах, уже работающих у пользователя.

***

Был когда-то такой анекдот:
-- Как отлаживать программу на ассемблере?
-- При помощи долгого и вдумчивого взгляда.

Так вот, сейчас я понимаю, что это не анекдот.

3. Третий метод отладки -- это долгий вдумчивый взгляд на код.

Он не настолько успешен, как первые два. Сложные ошибки им не найти. Когда же приходится им пользоваться? Когда есть проблемы с обоими первыми методами. Я лично встречаюсь с таким при работе с микроконтроллерами. Интерактивная отладка там есть -- и она очень помогает в тех случаях, когда программируемый процесс можно прервать. А вот вместо отладочной печати там есть только "отладочный массив". И разбирать его гораздо сложнее и неудобнее, чем просто посмотреть на свой код и немного подумать.

P.S. Некоторые среды разработки в сочетании с некоторыми типами микроконтроллеров позволяют выводить сообщения через программатор в специальное окно в среде разработки. Поэтому если это можно настроить то, конечно же, так и следует сделать.

Comments

[korrshun]

у нас почему-то наоборот преподы учили дебаггеру, а вот про отладочные принты всегда отзывались с пренебрежением.
и при этом все самые хитрожопые ошибки я находил именно чтением дебажных логов и вдумчивым курением исходников с рисованием на бумажке диаграмм.
Поставленный в правильном месте log.debug - это прямо отличная вещь, т.к. можно оттрасировать запрос, проходящий через пачку разных сервисов.
А дебаггером я уже почти разучился пользоваться, т.к. ну остановился ты на брекпойнте, походил туда-сюда, посмотрел на кишки, но всё равно выходит как в анекдоте

Василий Иванович: Петька,приборы!

Петька: 300!

Василий Иванович: Что 300?

Петька: А что приборы?

[баянолог]

Тоже постоянно пользуюсь третьим методом. Потому-что на plc ни брекпойнт нормально не поставишь, ни логов не сделаешь. Вот и приходится в голове эмулятор запускать. 

[zHz00]

korrshun, нам не рассказывали ни про интерактивную, ни про печать. Или рассказывали вскользь. Я тоже студентам не рассказывал, пока до меня не дошло, что чем на лабах это каждому отдельно объяснять, лучше прямо на лекции.

А почему пренебрежительно про отладочную печать? Если у преподов проекты, где можно без этого метода обойтись, то у них простая работа))) (если конечно они программируют, а не просто лекции читают).

[zHz00]

баянолог, в свете этого почта -- а у тебя ударение в нике на какой слог ставится? На последний?)

Да-да, долгий вдумчивый взгляд на самом деле -- эмулятор в голове. Я про это в посте не написал, но так и есть).

[anhelmoders]

Я не специалист, поэтому вот тебе мем))

[zHz00]

anhelmoders, у меня была именно такая история как на первой картинке -- на лабе по микропроцессорам нам выдали макет процессора 8080 и мы на нём чего-то курочили. А потом нам сказали, что есть доп. задание. И я, конечно, согласился. Как ни странно, кроме меня согласилась только одна девица (!). После этого нам выдали макет уже 8086 (родоначальника большинства современных процессоров для ПК), а заданием было написать программу умножения двух чисел прямо на процессоре. При этом даже ассемблера не было, у нас вместо этого была брошюра с инструкциями о том, как переводить ассемблер в машинные коды. И их надо было вводить прямо в память при помощи цифр. Мы сделали.

[korrshun]

zHz00, первый препод был человеком старой закалки, который начинал писать код ещё на перфокартах и интерактивный дебаггер в Turbo Pascal 7.0 был великим достижением и прогрессом, так что по его мнению, принты - это неудобный и устаревший способ.
Последующие преподы, имеющие отношение к программированию, были повёрнутыми на голову жабистами и шарпеями(C#), которые не мыслили жизни без IDE. В те годы было ещё популярно писать двухзвенки (БД на хранимых процедурах+толстый клиент на жабе/C#/дельфи) и продавать их как коробочный продукт/писать своё в крупных компаниях, и потому они учили нас тому, что по их мнению было важно. Писать много логов на машину клиента считалось тогда некомильфо, т.к. диск быстро заполнялся, да и от пользователя было можно добиться максимум - "я что-то нажала и всё исчезло". Поэтому единственным разумным способом они считали поставить бряки на нужные кнопки в UI и протыкать их так, как сказал юзер. Вебчик в их глазах был какой-то маргинальной фигнёй, на которой не заработать много денег.
Это уже потом, как я доучился, пришла мода на большой серверный веб и повальную телеметрию - читай слежка за юзером и сбор всего, до чего можно дотянуться, авось пригодится.
Эмбеддед же всегда был очень своеобразной нишей со своими правилами и нас ему по сути не учили.

[zHz00]

korrshun, ох, спасибо большое за исторический экскурс, а можешь сказать года основных событий?

Что писать логи не комильфо -- интересное мнение. Мы по приборам писали логи э... всегда. Ещё до моего прихода (я при возможности спрошу, когда это началось). Просто у нас написано держать логи за месяц, а потом автоматически стирать, поэтому винчестер не забивается.

[korrshun]

zHz00, я учился с 2005 по 2010й. В те годы в наших провинциях была повальная мода на дельфи/билдер/вижак, даже жаба казалась чем-то новомодным. И интернет был медленный, тарифицировался помегабайтно, и был повальный IE6, который медленно, но верно жрали фаерфоксы/оперы, так что веб казался чем-то далёким.

А логи писать было довольно бесполезно, юзеры были хитрые и могли попросту их удалить. Плюс, иногда случались грабли в виде какого-нибудь неочевидного зацикливания (на групповых операциях в табличках) и диск забивался мгновенно. Так что их мало ограничивать по дате, по-хорошему надо запиливать дедубликацию записей и ограничение на размер файла. Это на тот момент не поддерживалось ни одним логгером (да и сейчас пойди-найди такой умный). Простое ограничение размера не катит - если просто оставлять n последних строк, то реальная причина зацикливания просто затирается однотипными записями. Вот что было реально принято - писать триггерами таблички аудита, чтобы можно было посмотреть кто нагадил и потом откатить данные. Ну и логи писать тоже прямо в БД внутри хранимок, только главное - не говорить об этом тем преподам, они уже были отравлены жабой и считали хранимые процедуры устаревшим немасштабируемым зашкваром и считали, что ORM - это наше всё (ну а вдруг нам захочется поменять движок БД года через три?). Каюсь, я тоже в какой-то момент наивно полагал, что вся бизнес-логика должна максимально упихиваться в серверный код и как диплом писал типовую трёхзвенку на жабе. Но дебажные логи я тогда уже писал, потому что как иначе отладить сервер, который может бежать фиг знает где? Так что разговор про вред логов был главным образом про тогдашний десктопный софт.
А все микроконтроллерщики были на другой кафедре, так что я толком не знаю, что там у них было принято. Но про svn и wiki на проектах они тогда не слышали в отличие от нас - это 100%. Обходились папочками по датам с текстовыми файлами.

[zHz00]

korrshun, вот это да, всего 10 лет прошло.

Про логгер -- у нас логгер и разбивает файлы по размеру и следит за датой, он самописный. Определения дублирования строк нет, а ведь это хорошая идея, спасибо! В случае зацикливания действительно наш логгер может забить винчестер, но такого не происходит, поскольку наши зацикливания медленно генерят файл.

>>вся бизнес-логика должна максимально упихиваться в серверный код

Ты имеешь ввиду, что на самом деле надо часть убирать в хранимые процедуры?

>>типовую трёхзвенку

Как официально называется то, о чём ты говоришь?

>>Обходились папочками по датам с текстовыми файлами.

Когда я пришёл на текущую работу, то первое, что я сделал -- это ввёл SVN. До меня программиста было полтора, и они обходились ручным мержем и папочками по датам.

[anhelmoders]

zHz00, 

>Мы сделали.

крутаны! *_*

[баянолог]

zHz00, >> а у тебя ударение в нике на какой слог ставится? На последний?) 
на предпоследний. до того, как уйти в асутп, писал на sybase power builder. его ласково называли баяном. как-то так и ник получился.

[korrshun]

> типовую трёхзвенку

https://ru.wikipedia.org/wiki/%D0%A2%D1%80%D1%91%D1%85%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D0%B5%D0%B2%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0
Связка вида: тонкий клиент, чисто рисующий формочки - толстый сервер приложений со всей логикой и имеющий состояние - тупая БД в которой данные только хранятся.
По факту сейчас многие приложения из себя представляют связку:
Толстый клиент на вебе и/или на мобилке - большой или маленький ворох простых приложений-сервисов, тоже содержащих логику - много разных БД для хранения и in-memory БД для кеша типа редиса. И пофигу как эти сервисы написаны - на хранимках, на внутренней логике, лишь бы большинство из них не держало состояние в локальной памяти и было +- идемпотентным в большей части API - тогда их легко масштабировать горизонтально.
Многомудные преподы даже не догадывались о том, что жизнь повернётся именно так.

> Ты имеешь ввиду, что на самом деле надо часть убирать в хранимые процедуры?

Я не вижу в хранимках почти ничего плохого, потому что они работают довольно быстро и годятся для оптимизации некоторых мест, чтоб не гонять много данных туда-сюда между БД и аппсервером. Их только довольно сложно готовить - хороших инструментов для их отладки, профилирования и деплоя крайне мало. Равно как и людей, умеющих их писать и саппортить.