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

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

Но тут не существует волшебного набора правил. Я не могу выдать вам список из 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
Про четырехмесячный дебаг

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