четверг, ноября 26, 2009

Искусство отладки

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

Я решила сделать серию постов про отладку, где соберу накопившиеся у меня материалы. Тут будет некоторое количество моих собственных спорных мыслей. И я дам ссылки на байки о багфиксе, чтобы было не так скучно. Как обычно приглашаю всех подискутировать и поделиться накопившейся мудростью. :-)

Поскольку получилось много, повествование разбито на части.

1. Введение.
То, что вы читаете прямо сейчас.

2. Как предупредить появление багов.
Предупреждать всегда лучше чем лечить.

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

4. Технологии будущего.
Странные подходы, которые могут привести к тому, что отладкой больше заниматься не придется. А могут и не привести.


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

Следующей проблемой в борьбе с багами является Миф о Старании и Аккуратности. Удивительно живучая штука, и мне совсем непонятно откуда она взялась. Миф состоит в том, что если вы аккуратны, то багов у вас не будет. Вот так всё просто. Если у вас много багов, то это означает, что вы мало стараетесь. Это не так, баги не лечатся старанием. Поверьте, я очень аккуратный человек. Меня не раздражает монотонная работа, я могу по десять раз проверять одно и то же и это не вызывет приступ тихого бешенства. Но я не могу писать код без багов.

Приступать к борьбе с багами можно только если багфиксинг не вызывает у вас неприязни, чувства вины и страданий по поводу несовершенства Вселенной. Программистов, которые пишут код без багов, не существует. Те, кто любит рассказывать о своем умении писать безбажный код, нагло гонят. Научитесь писать код без багов и вы прославитесь и разбогатеете. Я серьезно.

Ну чего, в путь. И помните, Developers are born brave :-)



Байки:
Про вампиров
Про 500 миль


Книги:
"Совершенный код" Макконелла. Глава 23 полностью посвящена отладке.
David Agans "Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems". Напишу по этой книге отдельный пост как только ее прочитаю.

Updated 29.11.2009
В комментариях заинтересовались непрестижностью отладки. Вот очень жизненный пост про это:
пионеры, поддержка, и Доктор Хаус. Там есть байка про белые точки. (Нашла по ссылке отсюда)

16 коммент.:

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

Внесу свои 5 копеек (про программерские байки). В Израиле закупили новый военный самолет. Однако на испытаниях оказалось, что при полете над морем его бортовой компьютер все время перезагружается. Проверка показала, что причина в ... делении на ноль :) Дело в том, что Мертвое Море находится ниже уровня моря, и пролетая над его поверхностью, самолет пересекал нулевой уровень. Не учли программисты, что самолет может лететь ниже уровня моря :)

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

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

Т. е. в этом плане продукт обязан быть безбаговым и, более того, разработчик должен это доказать заказчику.

Повторюсь, знаю это все лишь в теории, на практике не занимался пока. Учусь.

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

embarger

google Theorem Prover's, Dependent Type Theory.

packages: coq,Agda2 and some more.

Мазов Гоша aka Carc комментирует...

А как же Роббинс, "Отладка приложений"? Имхо, без него будет неполно...
Вообще по-моему у него несколько книг: в том числе и "отладка NET" и еще что-то. Но была и первая, она поконцептуальнее что ли. Может стоит задеть и ее?

Алёна комментирует...

2embarger:

Мне известно, что есть такая штука, как математическое подтверждение того, что ваша программа работает так, как должна.

Угу, есть такая штука.

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

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

2Мазов Гоша aka Carc:
А как же Роббинс, "Отладка приложений"? Имхо, без него будет неполно...

Не читала. Ну комментарии они собственно как раз для этого. Если что-то читали и рекомендуете, то добавляйте в комментарии.

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

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

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

Вот ещё презабавная книжка http://torrents.ru/forum/viewtopic.php?t=2336079

Игорь Говоров комментирует...

Баек немалое количество (и философии на тему отладки и нестабильностей) есть в ЖЖ у ddima, например недавнее про setlocale или четырёхмесячный дебаг. Ну и вообще все его посты с названием "Рецепты отладки".
Некоторые вещи спорны, но в целом довольно продуманная позиция.

Yuriy Volkov комментирует...

из университетского курса вспомнились слова "валидация, верификация" и т.д. - совсем не ожидал их увидеть в одной из групп на LinkedIn - "Jr. Software Engineer. will work on a team responsible for the development and testing of the Command and Data Handling (C&DH) Software for the Orion (CEV) Space Vehicle using Honeywell Software Development Model" - "The engineer is to create unit tests, verification tests, analysis procedures, as well as validation and delivery processes". Про то как пишут код в NASA ходят слухи что он не содержит ошибок. Кроме того у Pragmatic Programmers недавно вышла книга Debug It!: Find, Repair, and Prevent Bugs in Your Code, сам я ее к сожалению не читал.

Алёна комментирует...

2aa10a:
почему же искать и править баги - непрестижно?
по-моему, одна из главных радостей программиста - найти, понять и исправить ошибку :)


Очень немногие так думаю, к сожалению...

2Игорь Говоров:
Баек немалое количество (и философии на тему отладки и нестабильностей) есть в ЖЖ у ddima, например недавнее про setlocale или четырёхмесячный дебаг. Ну и вообще все его посты с названием "Рецепты отладки".

Угу, видела, обязательно дам ссылки в третьей части.


2Yuriy Volkov:
Про то как пишут код в NASA ходят слухи что он не содержит ошибок.

Тоже слышала про это. Но я так и не поняла, они формально как-то доказывают, что ошибок нет в принципе или у них просто очень суровое тестирование идет.

Кроме того у Pragmatic Programmers недавно вышла книга Debug It!: Find, Repair, and Prevent Bugs in Your Code, сам я ее к сожалению не читал.

О, не знала. Достойные ребята, это надо читать.

Евгений Охотников комментирует...

О том как пишут софт в NASA когда-то писали здесь: They Write Right Staff (скорее всего, речь идет не о всем NASA, иначе не объяснить проблем с марсианским спутником, в котором не согласовали системы измерений).

Про то, что исправление багов -- это непрестижное занятие было интересно узнать. Никогда такого не наблюдал. Это действительно случается?

Что касается чувства вины за баги... Сам по себе баг в коде -- это нормально. Ненормально, когда баги попадают в финальную версию. И еще хуже, когда разработчики относятся к этому, как к обычному явлению (ну баг, ну и что?).

Ну и таки да: чем больше думаешь в начале, тем меньше отлаживаешься в конце. И аккуратность здесь не при чем.

Алёна комментирует...

2Евгений Охотников:

Про то, что исправление багов -- это непрестижное занятие было интересно узнать. Никогда такого не наблюдал. Это действительно случается?

Угу. Причем часто.

Что касается чувства вины за баги... Сам по себе баг в коде -- это нормально. Ненормально, когда баги попадают в финальную версию. И еще хуже, когда разработчики относятся к этому, как к обычному явлению (ну баг, ну и что?).

Баланс важен, ага.

Евгений Охотников комментирует...

>Это действительно случается?

Угу. Причем часто.


Спасибо, буду иметь в виду.

Кстати, о том, как стараются минимизировать количество ошибок в околовоенных разработках с использованием SPARK/Ada можно почитать в описании проекта Tokeneer. В отличии от разных theorem prover-ов это уже вполне промышленный подход.

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

2aa10a:

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


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

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

>Миф состоит в том, что если вы
>аккуратны, то багов у вас не будет.

Тут легко впасть в противоположную крайность. А именно "старайся или не старайся, а багов будет одинаковое количество". Это не так. Число багов зависит от внимательности очень заметным образом. Я знаю программистов, которые пишут по принципу "поскорее разделаться и перейти к другой задаче. а баги искать - задача тестеров". Другие же программисты тщательно вычитывают написанный код по нескольку раз, прогоняют множество тестов и т.п. Количество багов у второй группы в разы меньше. Так что, аккуратность и старательность не стоит недооценивать. :)

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

Цены Вам нет,Алёна. Если,конечно,напишется так,как задумано.Без багов...