x
 
Василий
9 августа 2018
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Как бороться с багами? Часть восьмая: порефлексировать


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

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

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

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

  • Понимание задачи. Что осталось непонятным или упущенным на этапе проектирования? Какие краевые случаи мы не учли?
  • Архитектура приложения. Что не учли или используем неправильно? Как обрабатываем ошибки? Как работаем с сетью и сторонними сервисами? Каких ограничений в базе данных не хватает?
  • Тестирование. Были ли тесты? Почему пропустили ошибку? Нет ли ошибок в самих тестах? Каких тестов не хватает?
  • Образование. Каких знаний об используемых технологиях не хватает? Чем мы пользуемся неправильно? Какие пробелы в наших стандартах? Что разработчики не знают о том, как программа эксплуатируется?
  • Люди. Нет ли проблем с внимательностью из-за переработок или выгорания? Нет ли проблем с дедлайнами? Может, в этом процессе вообще не должен участвовать человек?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • В Бюросфере

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

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

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

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

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

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

  • В Школе бюро

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

См. Brakeman

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

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

Пусть потеет машина

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

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

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

Ещё по теме

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

P. S. Это был совет о веб-разработке. Хотите знать всё о коде, тестах, фронтенд-разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.
Вёрстка и прототипирование — дисциплина Школы дизайнеров. Набор весной. Оставьте почту, и мы напишем вам, когда откроется следующий набор.
 

Поделиться
Отправить

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Каким способом сделать простую анимацию на спрайтах Как устроена беспарольная аутентификация почтой 7




Недавно всплыло

Как избежать «эффекта Тильды»? 2 4 3 Практика: формулировка полезного действия 8