Как описывать баги
Разработчики не любят баги и хотят от них поскорее избавиться. Если непонятно описать проблему, то, скорее всего, вам ответят «не воспроизводится». Никому не хочется разбираться в непонятной фигне.
Мне при описании багов другим разработчикам помогает алгоритм:
- что я сделал;
- что хотел получить;
- что получил в итоге.
В нём несколько плюсов.
Понятно, в чём баг
Не всегда очевидно то, что кажется очевидным.
Когда вы с разработчиком ещё не говорите на одном языке, «поправь отступ» для последнего превращается в квест. Сделать меньше, больше, кратным 5, убрать его вообще? «Увеличь отступ на 5 пк» — понятнее.
Если проблема сложная, то одной строчкой не обойдёшься. «Что хотел получить и что получил» сразу показывают на примере, как программа должна работать, а как нет.
Понятно, как воспроизвести
Отмазка «не воспроизводится» уже не прокатит, потому что вы уже написали, как его воспроизвести
Особенно эффективно работает, если указать контекст: браузер, размер экрана
Запись окружения можно автоматизировать. Например, у Жиры есть расширение для браузера, которое во время скриншота записывает браузер, разрешение экрана и операционную систему.
Вас всё равно спросят
Если что-то останется непонятно, вас всё равно об этом спросят, а время уйдёт впустую.
Я заметил, что когда описываю проблему подробно, то на её решение уходит меньше времени. Это относится не только к разработчикам, но и к поддержке, чату в банке. Опишу проблему сразу подробно — меня не дёргают потом за уточнениями.
Конечно, не для всех ситуаций это нужно. «Поменяй цвет ссылки на синий» — тут всё и так ясно. А вот если команда ещё не сработалась, или проблема сложная, то чем подробнее, тем лучше.