Отладка кода занимает больше времени чем разработка. Но почему-то этой теме уделяется удивительно мало внимания. Вы легко найдете пачку пухлых книг про синтаксис языка, про алгоритмы, а вот с отладкой дела обстоят похуже. В вузах про отладку если и рассказывают, то мало, поэтому зачастую нетривиальные баги вызывают панику и беспомощность.
Я решила сделать серию постов про отладку, где соберу накопившиеся у меня материалы. Тут будет некоторое количество моих собственных спорных мыслей. И я дам ссылки на байки о багфиксе, чтобы было не так скучно. Как обычно приглашаю всех подискутировать и поделиться накопившейся мудростью. :-)
Поскольку получилось много, повествование разбито на части.
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
В комментариях заинтересовались непрестижностью отладки. Вот очень жизненный пост про это:
пионеры, поддержка, и Доктор Хаус. Там есть байка про белые точки. (Нашла по ссылке отсюда)
That IACR preprint
3 дня назад
Atom feed
16 коммент.:
Внесу свои 5 копеек (про программерские байки). В Израиле закупили новый военный самолет. Однако на испытаниях оказалось, что при полете над морем его бортовой компьютер все время перезагружается. Проверка показала, что причина в ... делении на ноль :) Дело в том, что Мертвое Море находится ниже уровня моря, и пролетая над его поверхностью, самолет пересекал нулевой уровень. Не учли программисты, что самолет может лететь ниже уровня моря :)
Мне известно, что есть такая штука, как математическое подтверждение того, что ваша программа работает так, как должна. Я понятия, откровенно говоря, не имею, как это реализует на практике, но знаю, что продукты, связанные с защитой информации, никогда не пройдут сертификацию (а может и не найдут покупателя) без подобного доказательства.
Т. е. в этом плане продукт обязан быть безбаговым и, более того, разработчик должен это доказать заказчику.
Повторюсь, знаю это все лишь в теории, на практике не занимался пока. Учусь.
embarger
google Theorem Prover's, Dependent Type Theory.
packages: coq,Agda2 and some more.
А как же Роббинс, "Отладка приложений"? Имхо, без него будет неполно...
Вообще по-моему у него несколько книг: в том числе и "отладка NET" и еще что-то. Но была и первая, она поконцептуальнее что ли. Может стоит задеть и ее?
2embarger:
Мне известно, что есть такая штука, как математическое подтверждение того, что ваша программа работает так, как должна.
Угу, есть такая штука.
Я понятия, откровенно говоря, не имею, как это реализует на практике, но знаю, что продукты, связанные с защитой информации, никогда не пройдут сертификацию (а может и не найдут покупателя) без подобного доказательства.
Из того, что мне известно про формальное доказательство правильности программ - это сложная и объемная штука и она совершенно не подходит для больших промышленных проектов. Можно применять это к функции, которая какую-нибудь математику считает.
2Мазов Гоша aka Carc:
А как же Роббинс, "Отладка приложений"? Имхо, без него будет неполно...
Не читала. Ну комментарии они собственно как раз для этого. Если что-то читали и рекомендуете, то добавляйте в комментарии.
почему же искать и править баги - непрестижно?
по-моему, одна из главных радостей программиста - найти, понять и исправить ошибку :)
Вот ещё презабавная книжка http://torrents.ru/forum/viewtopic.php?t=2336079
Баек немалое количество (и философии на тему отладки и нестабильностей) есть в ЖЖ у ddima, например недавнее про setlocale или четырёхмесячный дебаг. Ну и вообще все его посты с названием "Рецепты отладки".
Некоторые вещи спорны, но в целом довольно продуманная позиция.
из университетского курса вспомнились слова "валидация, верификация" и т.д. - совсем не ожидал их увидеть в одной из групп на 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-ов это уже вполне промышленный подход.
2aa10a:
почему же искать и править баги - непрестижно?
по-моему, одна из главных радостей программиста - найти, понять и исправить ошибку :)
Понять и исправить - это круто. А вот париться три дня, ломая мозг и не находить в чём косяк - это не очень-то приятно. Хорошо, когда этого пытаются избежать грамотным проектированием и юниттестированием, но страусиный метод ещё менее трудозатратен.
>Миф состоит в том, что если вы
>аккуратны, то багов у вас не будет.
Тут легко впасть в противоположную крайность. А именно "старайся или не старайся, а багов будет одинаковое количество". Это не так. Число багов зависит от внимательности очень заметным образом. Я знаю программистов, которые пишут по принципу "поскорее разделаться и перейти к другой задаче. а баги искать - задача тестеров". Другие же программисты тщательно вычитывают написанный код по нескольку раз, прогоняют множество тестов и т.п. Количество багов у второй группы в разы меньше. Так что, аккуратность и старательность не стоит недооценивать. :)
Цены Вам нет,Алёна. Если,конечно,напишется так,как задумано.Без багов...
Отправить комментарий