[comp.prog.bugs] Серия заметок про отладку в блоге “Алёна С++”

В блоге “Алёна С++” началась публикация серии заметок про отладку, уже опубликованы первая (“Искусство отладки”) и вторая (“Искусство отладки: как предупредить появление багов”) части.

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

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

Впрочем, старым и матерым программистам так же может быть интересно. Я, например, с удивлением для себя обнаружил, что существует такой феномен, как “отладка – это не престижно”. Никогда с таким не сталкивался раньше. Встречал мнение, что программирование – это ерунда, а вот разработка архитектуры – это круто. А так же с мнением, что и разработка архитектуры это ерунда, а вот создание математических моделей… Теперь вот узнал про то, что для некоторых отладка – это не престижно. Век живи, век учись.

Нужно отдать должное Алёне Сагалаевой. Она решилась затронуть большую и сложную тему. Я бы не отважился. Во-первых, у меня вылавливать баги получается, но как я это делаю – я и сам понятия не имею. Во-вторых, я убежден, что гораздо лучше обучают отладке описания конкретных примеров поиска ошибок, а не абстрактные правильные вещи (вроде хорошей архитектуры и использования unit-тестов). Например, многие начинающие программисты не знают, что при отладке можно просто напросто комментировать часть кода или же заменять его специальными заглушками-имитаторами. Поскольку про пошаговый отладчик они быстро узнают, а вот о таких приемах могут не знать довольно долго.

Ну и в завершение размышлизм :) Придумалась метафора. Разработка программ с помощью методов, которые значительно уменьшают количество багов (unit-тесты, статическая типизация, Design By Contract, хардкорная функциональщина с зависимыми типами и пр., языки спецификаций и инструменты верификации программ) – это как проектирование корабля с повышенной живучестью. Фанаты подобных инструментов могут искренне верить в то, что можно построить непотопляемый корабль.

А средства поиска и устранения багов – это как оснащение такого корабля средствами спасения на случай, если он все-таки пошел ко дну.

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