Промышленное программирование

Лекция 7. Отладка и профилирование

Отладка

Как известно, программа делает не то, что от нее ожидают, а то, что написано у нее в коде
Программа, которая делает не то, что от нее ожидают никому не нужна
Задача программиста - сделать так, чтобы код программы описывал то, что от этой программы ожидают
В некоторых ситуациях сделать так, чтобы программа вела себя ожидаемым образом, бывает затруднительно
Задача отладки (debugging) - помочь программисту понять, почему программа ведет себя не так, как ожидается
Зачастую для этого необходимо уметь залезать "внутрь" программы и поэтапно следить за тем, что она делает

Printf

“The most effective debugging tool is still careful thought, coupled with judiciously placed print statements” — Brian Kernighan, Unix for Beginners.
Самый простой (и тем не менее действенный) способ понять, что же на самом деле делает программа - вывести ее внутреннее состояние на различных этапах исполнения
В процессе отладки можно более точно определять момент (и код), когда что-то идет не так, и уже более детально исследовать состояние программы
Обычно printf (или аналоги) добавляют временно для понимания происходящего, после чего удаляют
Кроме этого, можно изначально писать код таким образом, чтобы программа логировала что она делает с разной степенью точности

Логирование

У регулярных логов есть преимущества по сравнению с временными printf-ами
У логов есть разные уровни (обычно DEBUG, INFO, WARN, ERROR), и в зависимости от ситуации можно оставлять информацию определенных уровней
Логи, обычно, добавляются до того, как будут обнаружены проблемы, и всегда есть шанс, что только их хватит (что сильно упрощает жизнь в случае трудно воспроизводимого бага)
Сравнение логгеров для C++
В python можно использовать стандартный пакет logging (примеры)
В Golang есть не очень удобный стандартный пакет log, более удобная альтернатива zap

Форматирование логов

При логировании нужно уметь найти баланс между детализированностью и информатированностью
Запись чего-либо в лог имеет накладные расходы. Более того, логи могут аггрегироваться по сети с различных инстансов, а не просто писаться в файл
Что обычно добавляют в лог: время (или timestamp) записи в лог, уровень логирования, модуль или часть системы при необходимости, место в коде (где случилась запись в лог или где произошла ошибка), инстанс или хост, откуда прилетел лог

Форматирование логов

Кроме этого, лог должен содержать внятное описание что конкретно произошло в данном месте, и, возможно, некоторую дополнительную информацию (например, для access лога полезно иметь ip-адрес, user agent, uri запроса, ...)
Форматировать логи нужно в соответствии с предполагаемым использованием, например: цветной человекочитаемый вывод при локальном запуске, json (или другой структурированный) формат в других окружениях
Для цветного форматирования есть специальные последовательности в терминале: echo -e "\e[31;1mThis is red\e[0m"

Логи сторонних систем

Почти всегда в проекте используются сторонние системы, в которых тоже что-то может пойти не так: вебсерверы (или reverse proxy), базы данных, очереди задач, ...
Информативность логов сторонних систем обычно остается на совести разработчиков, однако популярные решения обычно дают достаточно информативные логи
В UNIX системах обычно принято складывать логи в /var/log/, например логи nginx живут в /var/log/nginx
Системные логи можно также поискать в /var/log/journal или использовать journalctl (Linux) или log show (macOS)

Отладка

Несмотря на полезность логов, часто бывают ситуации, когда не понятно, где же на самом деле ошибка
В таких ситуациях необходимо научиться воспроизводить ошибку, в чем почти всегда помогают информативные логи - например, какие действия делал пользователь
(После того, как стали понятны шаги для воспроизведения ошибки, хорошо бы написать на нее тест)
В простых сценариях можно наставить printf в интересующих нас местах для того, чтобы узнать внутреннее состояние, приводящее к ошибке
В более сложных сценариях более продуктивно использовать отладчик (debugger)

Отладка

Отладчик позводяет управлять исполнением программы и на лету исследовать внутреннее состояние
Мы можем останавливать исполнение программы в интересующие нас моменты времени и запускать исполнение шаг за шагом, исследуя состояние
Для разных языков существуют разные популярные отладчики: C/C++ - gdb (и lldb), Python - pdb (и opdb), Go - delve
Наиболее удобный (хотя и менее гибкий может быть в редких кейсах) способ запустить отладчик - использовать функциональность IDE

strace

strace позволяет отслеживать системные вызовы процесса
На macOS (и BSD) есть альтернатива - dtrace (с отличным от strace синтаксисом команд)
```
  # On Linux
  sudo strace -e lstat ls -l > /dev/null
  4
  # On macOS
  sudo dtruss -t lstat64_extended ls -l > /dev/null
```

tcpdump

tcpdump - анализатор сетевого трафика, позволяет исследовать сетевые пакеты
Очень часто бывает полезен для отладки сетевых приложений, в том числе на продакшене
Для работы с ним нужно хотя бы примерно понимать как работает сеть на уровне операционной системы
Кроме этого, можно использовать Wireshark

Статический анализ

Статический анализ позволяет выявлять потенциальные проблемы в коде анализируя конструкции
Для C++ можно найти тут
Для Python можно найти тут
Для Go - go vet (базовый из коробки), golangci-lint, ...

Профилирование

Даже если программа работает так, как ожидается, она может это делать медленно или с большим потреблением памяти
Профилирование помогает разложить на составляющие общее время и выделяемую память, что позволяет найти проблемные места в коде
Большинство профайлеров можно отнести к одной из двух групп: tracing и sampling (подробнее)
Для Python можно использовать cProfile, для Go - go tool pprof и стандартный пакет pprof

Thank you

Лекция 7. Отладка и профилирование