Искусство отладки: как предупредить появление багов

Очень хочется придушить все баги накорню. Совсем все придушить не получится, а вот сильно уменьшить их число - вполне.

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

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

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

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

Не забывайте про автоматическое тестирование. Добавляйте его где возможно.

Вообще написали что-то - проверьте. Не надо надеяться, что багов в вашем коде нет. Потому что они там есть. И чем раньше вы их поймаете, тем лучше. Сейчас, прямо после написания кода, вы хорошо его помните, это не займет много времени. Это гораздо быстрее чем прогонять код через команду тестирования и получить от них баги в багтрак через пару дней. Если нетривиальный кусок кода заработал сразу - это повод для беспокойства, значит вы что-то пропустили. Тут я очень советую почитать прекрасную статью написаннию тестером специально для программистов: Testing for developers.

Написав код, остановитесь, подумайте. Что будет если? Если числа выйдут за заданный диапазон? Что если мне здесь придет нулевой указатель? Как можно сломать мой код? Хотя если вы сейчас в кранче, то наверное не стоит тратить время на медитацию над этими вопросами. Однако, если время есть, то ответы на них спасут вам недели времени.

Хорошо помогает code review. Когда кто-то из ведущих программистов просматривает код остальных. Но осложняется человеческим фактором "как же так, кто-то будет проверять и править мой гениальный код?!". Поэтому code review может привести к боязни коммита и конфликтам в команде. Статья про code review: Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews.

Постоянная бдительность! Паранойя в разумных пределах есть благо. Наряду с вопросом "что будет если?" задавайтесь вопросом "почему?". Мы практически ничего не меняли в последнее время, а размер дистрибутива вырос, почему? Мы не меняли данные, однако SVN подсвечивает их как измененные, почему?

Очень важным индикатором проблемы является взрывной рост числа багов. Например, нам постоянно приходят баги из отдела тестирования по поводу работы со звуковой подсистемой. Причем проблемы одна страннее другой. Странные проблемы есть следствие странных решений. Мистически ломающиеся куски кода означают, что вы чего-то не понимаете. Когда нет понимания, вам начинают вспоминаться фазы луны, бубен и барабашка. Так вот, надо на мистически ломающийся кусок кода обратить самое пристальное внимание. Очень возможно, что источник всех этих проблем - один, а это его разные проявления. И это тот самый момент, где Старания и Аккуратность, упомянутые в прошлом посте, только усугубят ситуацию. Если вы будете старательно править баги, вместо того, чтобы разобраться с причиной, вы потеряете кучу времени и завяжете код узлом. Чем больше вы будете биться над кодом, тем сильнее затянется петля (см. симфоническую сказку Петя и Волк в качестве наглядной иллюстрации).

На сегодня, пожалуй, все. В следущий раз - основная тема. Как всё исправить.

Байки:
Про Блицкриг 2
Про четырехмесячный дебаг

Ссылки:
Отладка. Несколько советов.
Программистское: статистическая и доказательная стратегии защиты от ошибок (Тут есть бонусная байка про наковальню)

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

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

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

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

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
В комментариях заинтересовались непрестижностью отладки. Вот очень жизненный пост про это:
пионеры, поддержка, и Доктор Хаус. Там есть байка про белые точки. (Нашла по ссылке отсюда)

Приехали книги из Амазона

Сегодня ко мне приехали:

Debugging. Книга, целиком посвященная отладке. Заказала ее, потому что готовлю эпичную серию постов по этой теме.

Coders at work. Как Founders at work только про кодеров.

Game Programming Gems 6. Вообще уже вышла седьмая книга серии. Но, судя по отзывам, она неудачная. Так что я взяла шестую.

Warfare in the Medieval World. Про тактику средневековых сражений. Долго искала что-либо подобное, по описанию эта книга выглядит отлично, содержимое я скоро заценю.

По мере прочтения буду писать рецензии. :-)

Amazon.com не работает теперь с Почтой России и их можно понять. Доставляет всё очень быстро и очень дорого.

Язык программирования Go

Сегодня Google представил язык программирования собственной разработки под названием Go. Я почитала о нем наискосок, там есть сборка мусора, высказываются интересные мысли по поводу многопоточности. Пока ничего революционного не обнаружила.

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

Официальный сайт языка Go, там есть FAQ.

Новость пользуется популярностью, вот уже многопоточный рейтрейсер написали... A Multi-threaded Go Raytracer

Updated 20.11.2009
Ссылки по теме:
Краткий пересказ Effective Go на русском языке

Code reuse

Проблемы с code reuse испытывают средние и большие программерские компании. Это 50 или больше программистов, не все друг друга знают в лицо и не все знают кто над каким кодом работает. Вы пишите проприетарный софт, как-то его документируете, однако раз за разом наступаете на одну и ту же проблему. Различные группы программистов постоянно пишут один и тот же код, дублируя тем самым работу друг друга. Ситуация может осложняться еще и тем, что у компании может быть несколько географически удаленных друг от друга девелоперских офисов. Как решать эту проблему? Я видела три подхода, все плохие.

1. А никак. Живем с дублированием кода. Иногда страдаем по этому поводу.

2. Периодически устраиваем встречи, делаем красивые презентации, кидаем обширные письма в общую рассылку. Желающие могут взять код соседнего отдела и начать с ним работать. Однако народ на встречи зачастую не приходит, рассылку читает наискосок. Кто-то начинает форкать чужой код и вот у нас уже куча вариантов одного и того же, но с разным набором багов.
Итог: Code reuse местами присутствует.

3. Жесткая модульная система. Подробное документирование. За каждым модулем закреплен ответственный. Возможно, есть отдельные люди, которые следят за тем, чтобы дублирования кода не было.
Казалось бы, вот оно! Однако в итоге получаем падение морали и резкое снижение производительности труда. Потому что у нас все команды становятся завязаны друг на друга и никто старается ничего не менять, чтобы не стать тем самым виноватым, который всё сломал.

Наименее плохим, пожалуй, является второй вариант, но хочется большего. Может вы знаете другие прекрасные способы решения этой проблемы? Или книжки какие правильные? Подскажите!

Несколько старых интервью

Так получилось, что на прошлой неделе я прочитала/посмотрела несколько интервью с разработчиками. На случай, если вы их не видели:

Рассказ Джона Кармака на QuakeCon 2009:

Раз уж зашла об этом речь, вот презентация об их движке Tech5[.pdf]. Презентация красивая, но несколько бестолковая, мало подробностей.

Интервью с Дмитрием Ясеневым об искусственном интеллекте СТАЛКЕР'а:
S.T.A.L.K.E.R.: Чистое небо - интервью о проблемах выживания искусcтвенного интеллекта в Чернобыльской Зоне

Интервью с Тимом Суини о GPU (Спасибо Денису Баженову за ссылку):
Twilight of the GPU: an epic interview with Tim Sweeney