Профилактика багов
Как исправить баг
Порефлексировать
Управление багами
Профилактика багов
Как исправить баг
Порефлексировать
Управление багами
Когда баг исправлен, остаётся порефлексировать, ответив на два вопроса: что пошло не так и что сделаем, чтобы в будущем такого не было?
Что пошло не так?
Чтобы не допускать подобных ошибок в будущем, сначала надо понять, что не так в процессе разработки. Почему баг вообще появился в системе?
Чтобы ответить на этот вопрос, я прохожу по списку:
Понимание задачи. Что осталось непонятным или упущенным на этапе проектирования? Какие краевые случаи мы не учли?
Архитектура приложения. Что не учли или используем неправильно? Как обрабатываем ошибки? Как работаем с сетью и сторонними сервисами? Каких ограничений в базе данных не хватает?
Тестирование. Были ли тесты? Почему пропустили ошибку? Нет ли ошибок в самих тестах? Каких тестов не хватает?
Образование. Каких знаний об используемых технологиях не хватает? Чем мы пользуемся неправильно? Какие пробелы в наших стандартах? Что разработчики не знают о том, как программа эксплуатируется?
Люди. Нет ли проблем с внимательностью из‑за переработок или выгорания? Нет ли проблем с дедлайнами? Может, в этом процессе вообще не должен участвовать человек?
Что сделаем, чтобы в будущем такого не было?
Когда понятно в чём проблема с процессом разработки, остаётся придумать, как её исправить и исправить:
В Издательстве бюро
Первая версия билинга неправильно продлевала подписки: продление «на месяц» на самом деле продлевало подписку на 30 дней от текущей даты.
Причина — понимание задачи. Разработчики по‑своему поняли «подписка продлевается на месяц» и не согласовали, как на самом деле это должно было работать.
Чтобы в будущем таких проблем не было, обновляем стандарт, по которому пишутся спецификации: договариваемся все детали, касающиеся времени и дат, описывать развёрнутыми примерами:
В Школе бюро
Часть студентов, принятых на вторую ступень, не получила приглашения, потому что у них не было активных карт, привязанных в Бюросфере.
Причина — архитектура. Система, отправляющая приглашения, не учитывала, что карты могут истекать, а платёжный сервис быть недоступным, и не могла собрать письмо без информации о карте.
Чтобы в будущем таких проблем не было, учим приглашения работать и без карты, учим систему сигнализировать о проблемах с платёжным сервисом и нормально их переживать. Дополнительно перепроверяем другие сервисы, работающие с картами: все ли из них нормально переживают сбои в платёжной системе.
В Издательстве бюро
О Педанте рассказывал Сергей Фролов в Техноведре
Книги издательства бюро проверяет Педант. Он делает скриншоты разворотов в разных браузерах и сверяет их с эталонами.
О Педанте рассказывал Сергей Фролов в Техноведре
Арт‑директор находит проблемы в вёрстке в боевой версии книги, которые Педант пропустил:
Причина — тестирование. Библиотека, с помощью которой Педант сравнивает изображения, не видит разницы между двумя изображениями из‑за серого фона.
Чтобы в будущем таких проблем не было, заменяем библиотеку и перепроверяем самого Педанта.
В Бюросфере
Такой баг — XSS, одна из самых распространённых уязвимостей сайтов. См. XSS в Википедии
В Бюросфере нашли баг: пользователь может написать ХТМЛ в тексте о себе, который движок никак не фильтрует. Можно внедрить любой вредоносный код.
Такой баг — XSS, одна из самых распространённых уязвимостей сайтов. См. XSS в Википедии
Причина — образование. Разработчики не знали о XSS и других типичных уязвимостях в вебе.
Чтобы в будущем таких багов не было, организовываем Security Fridays. Каждую пятницу разработчики разбираются с типичными уязвимостями в вебе: как устроены, как используют, как защититься. В конце занятия разработчики получают домашку: дополнительное чтение по теме, задание найти похожую уязвимость на сайте бюро и исправить её.
См. Brakeman
Дополнительно подключаем автоматические линтеры, обнаруживающие типовые уязвимости.
См. Brakeman
В Школе бюро
Вступительные баллы на второй ступени считались вручную, а разработчики затем переносили их в базу данных. Это занимало пару дней и часто приводило к ошибкам.
Причина — люди. Процесс подсчёта вступительного балла на второй ступени вообще не должен был делать человек: это тупая и монотонная работа, в которой легко допустить ошибку.
Чтобы в будущем таких багов не было, заменяем человека программой: вся необходимая информация уже есть в базе данных, компьютер рассчитывает вступительный балл мгновенно и без ошибок.
См., например, триллер от Злых Марсиан о замалчивании исключений внутри транзакций
Советую для особо серьёзных багов фиксировать такие отчёты и делиться ими в блогах, рассылках и на митапах: другие разработчики научатся на чужих ошибках.
См., например, триллер от Злых Марсиан о замалчивании исключений внутри транзакций
Что запомнить
Когда баг исправлен, нужно порефлексировать: понять, что не так с процессом разработки (из‑за чего баг просочился?) и что сделать, чтобы в будущем таких багов не было.
Ещё по теме
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.