Профилактика багов
Как исправить баг
Управление багами
Профилактика багов
Как исправить баг
Управление багами
Когда баг стабильно воспроизводится, его нужно изолировать: определить проблемную подсистему, модуль или функцию и понять причину проблемы.
Этот процесс напоминает научные эксперименты: выдвигаем гипотезу (что может быть не так?), конструируем эксперимент, который её подтвердит или опровергнет (как это проверить?), разбираемся с результатами (что дальше?)
В Издательстве бюро
Авторы жалуются на переносы, появляющиеся после знаков препинания:
Гипотеза: модуль автоматической расстановки переносов глючит, он ставит переносы после знаков препинания. Эксперимент: убедиться, что в разметке есть символы мягкого переноса после знаков препинания. Результат: неправильных переносов нет. Значит, проблема в чём‑то другом.
Гипотеза: глюк Сафари. Эксперимент: убедиться, что неправильный перенос появляется только в Сафари, а в остальных браузерах его нет. Результат: неправильный перенос появляется только в Сафари.
Без стилей
Гипотеза: проблема появляется только в книге. Эксперимент: перенести ХТМЛ проблемного абзаца в отдельную страницу и посмотреть в Сафари. Результат: неправильный перенос появляется в Сафари и в случае с голым ХТМЛ. Значит, это системная проблема Сафари.
Без стилей
Гипотеза: проблема связана с разметкой. Эксперимент: удалить всю разметку из документа и посмотреть в Сафари. Результат: неправильный перенос исчез. Значит, проблема в разметке.
Гипотеза: проблема связана со спанами внутри параграфа. Эксперимент: вернуть спаны, убрать всё лишнее и посмотреть в Сафари. Результат: неправильный перенос вернулся. Значит, проблема в спанах.
Гипотеза: проблема в пробелах внутри спанов. Эксперимент: убрать пробелы и посмотреть в Сафари. Результат: неправильный перенос исчез. Значит, проблема возникает в том случае, когда авторы используют якоря, заканчивающиеся пробелом, внутри параграфов.
Отправляем багрепорт в Эпл, просим авторов не оставлять пробелы в якорях в параграфах.
При работе с багами, причина которых может быть в чём угодно, помогает метод деления пополам (двоичный поиск). Чаще всего этот метод применяют к проблемам в вёрстке:
В Школьном кабинете бюро
Преподаватели жалуются, что при выставлении оценок ссылка на работу студента исчезает. Оказывается, ссылку перекрывает залипающая шапка с оценками студента.
Делим стили шапки пополам, комментируем первую половину и проверяем. Проблема осталась, значит, дело в оставшихся стилях.
Делим оставшиеся стили пополам, комментируем первую половину. Проблема ушла, значит, дело во второй половине.
Продолжаем так до тех пор, пока не становится понятно, что дело в top: 100vh на одном из родителей.
В экспериментах советую опираться на инструменты отладки. Они помогают заглянуть внутрь работающего приложения: уточнить состояние переменных и данных, проверить ход и логику приложения. Подойдут как простые инструменты (console.log, console.trace, print), так и полноценные дебаггеры (byebug, debugger).
Когда гипотезы закончились, а точно объяснить баг не получается, стоит проверить исходные предположения:
В Издательстве бюро
Авторы жалуются, что иногда при переходе в книгу по ссылке она «соскакивает»: открывает не тот разворот, что был указан.
Когда ни одна из гипотез не подтвердилась, решили проверить исходные предположения. Что если проблема не в книге? Что если дело в бэкенде или веб‑сервере?
Когда стали проверять гипотезы о проблемах с веб‑сервером, оказалось, что он был настроен неправильно, и в некоторых случаях проксировал не тот урл в книгу: в урле был тридцатый разворот, а в книгу проксировался урл без номера разворота. Книга не видела указанный разворот и открывалась на последнем прочитанном развороте.
Что запомнить
Чтобы найти причину проблемы, строят гипотезы и проверяют их экспериментами, последовательно отвечая на три вопроса: что может быть не так, как это проверить, что дальше.
В гипотезах помогает метод деления пополам. В экспериментах — инструменты отладки.
Если гипотезы закончились, а причина всё еще не установлена, стоит проверить исходные предположения.
Ещё по теме
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.