Как описывать баги

Разработчики не любят баги и хотят от них поскорее избавиться. Если непонятно описать проблему, то, скорее всего, вам ответят «не воспроизводится». Никому не хочется разбираться в непонятной фигне.

Мне при описании багов другим разработчикам помогает алгоритм:

• что я сделал;
• что хотел получить;
• что получил в итоге.

В нём несколько плюсов.

Понятно, в чём баг

Не всегда очевидно то, что кажется очевидным.

Когда вы с разработчиком ещё не говорите на одном языке, «поправь отступ» для последнего превращается в квест. Сделать меньше, больше, кратным 5, убрать его вообще? «Увеличь отступ на 5 пк» — понятнее.

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

Понятно, как воспроизвести

Отмазка «не воспроизводится» уже не прокатит, потому что вы уже написали, как его воспроизвести 🙃

Особенно эффективно работает, если указать контекст: браузер, размер экрана и так далее. Здесь уж совсем деваться некуда.

Запись окружения можно автоматизировать. Например, у Жиры есть расширение для браузера, которое во время скриншота записывает браузер, разрешение экрана и операционную систему.

Вас всё равно спросят

Если что-то останется непонятно, вас всё равно об этом спросят, а время уйдёт впустую.

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

Конечно, не для всех ситуаций это нужно. «Поменяй цвет ссылки на синий» — тут всё и так ясно. А вот если команда ещё не сработалась, или проблема сложная, то чем подробнее, тем лучше.