Когда баг исправлен, остаётся порефлексировать, ответив на два вопроса: что пошло не так и что сделаем, чтобы в будущем такого не было?

Что пошло не так?

Чтобы не допускать подобных ошибок в будущем, сначала надо понять, что не так в процессе разработки. Почему баг вообще появился в системе?

Чтобы ответить на этот вопрос, я прохожу по списку:

  • Понимание задачи. Что осталось непонятным или упущенным на этапе проектирования? Какие краевые случаи мы не учли?

  • Архитектура приложения. Что не учли или используем неправильно? Как обрабатываем ошибки? Как работаем с сетью и сторонними сервисами? Каких ограничений в базе данных не хватает?

  • Тестирование. Были ли тесты? Почему пропустили ошибку? Нет ли ошибок в самих тестах? Каких тестов не хватает?

  • Образование. Каких знаний об используемых технологиях не хватает? Чем мы пользуемся неправильно? Какие пробелы в наших стандартах? Что разработчики не знают о том, как программа эксплуатируется?

  • Люди. Нет ли проблем с внимательностью из‑за переработок или выгорания? Нет ли проблем с дедлайнами? Может, в этом процессе вообще не должен участвовать человек?

Что сделаем, чтобы в будущем такого не было?

Когда понятно в чём проблема с процессом разработки, остаётся придумать, как её исправить и исправить:

В Издательстве бюро

Первая версия билинга неправильно продлевала подписки: продление «на месяц» на самом деле продлевало подписку на 30 дней от текущей даты.

Причина — понимание задачи. Разработчики по‑своему поняли «подписка продлевается на месяц» и не согласовали, как на самом деле это должно было работать.

Чтобы в будущем таких проблем не было, обновляем стандарт, по которому пишутся спецификации: договариваемся все детали, касающиеся времени и дат, описывать развёрнутыми примерами:

В примерах учитываем краевые случаи: февраль, конец месяца, конец года

В Школе бюро

Часть студентов, принятых на вторую ступень, не получила приглашения, потому что у них не было активных карт, привязанных в Бюросфере.

Причина — архитектура. Система, отправляющая приглашения, не учитывала, что карты могут истекать, а платёжный сервис быть недоступным, и не могла собрать письмо без информации о карте.

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

В Издательстве бюро

О Педанте рассказывал Сергей Фролов в Техноведре

Книги издательства бюро проверяет Педант. Он делает скриншоты разворотов в разных браузерах и сверяет их с эталонами.

О Педанте рассказывал Сергей Фролов в Техноведре

Арт‑директор находит проблемы в вёрстке в боевой версии книги, которые Педант пропустил:

Серого фона у лейбла точно не должно быть

Причина — тестирование. Библиотека, с помощью которой Педант сравнивает изображения, не видит разницы между двумя изображениями из‑за серого фона.

Чтобы в будущем таких проблем не было, заменяем библиотеку и перепроверяем самого Педанта.

В Бюросфере

Такой баг — XSS, одна из самых распространённых уязвимостей сайтов. См. XSS в Википедии

В Бюросфере нашли баг: пользователь может написать ХТМЛ в тексте о себе, который движок никак не фильтрует. Можно внедрить любой вредоносный код.

Такой баг — XSS, одна из самых распространённых уязвимостей сайтов. См. XSS в Википедии

Причина — образование. Разработчики не знали о XSS и других типичных уязвимостях в вебе.

Чтобы в будущем таких багов не было, организовываем Security Fridays. Каждую пятницу разработчики разбираются с типичными уязвимостями в вебе: как устроены, как используют, как защититься. В конце занятия разработчики получают домашку: дополнительное чтение по теме, задание найти похожую уязвимость на сайте бюро и исправить её.

См. Brakeman

Дополнительно подключаем автоматические линтеры, обнаруживающие типовые уязвимости.

См. Brakeman

В Школе бюро

Вступительные баллы на второй ступени считались вручную, а разработчики затем переносили их в базу данных. Это занимало пару дней и часто приводило к ошибкам.

Причина — люди. Процесс подсчёта вступительного балла на второй ступени вообще не должен был делать человек: это тупая и монотонная работа, в которой легко допустить ошибку.

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

См., например, триллер от Злых Марсиан о замалчивании исключений внутри транзакций

Советую для особо серьёзных багов фиксировать такие отчёты и делиться ими в блогах, рассылках и на митапах: другие разработчики научатся на чужих ошибках.

См., например, триллер от Злых Марсиан о замалчивании исключений внутри транзакций

Что запомнить

Когда баг исправлен, нужно порефлексировать: понять, что не так с процессом разработки (из‑за чего баг просочился?) и что сделать, чтобы в будущем таких багов не было.

Ещё по теме

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Веб‑разработка
Отправить
Поделиться
Запинить

Рекомендуем другие советы