После рабочего звонка я открываю таск-трекер Jira и просматриваю все задачи, назначенные за меня. Там хаос, потому что многие задачи живут месяцами в ожидании вялых ответов от пользователей. Поэтому каждый день я проверяю не появилось ли нового ответа, следуя стандартному процессу. Процесс выглядит в среднем так:
- Прилетает задача с описанием "нихуя не работает! Вообще пиздец!" и 3 минутный видос, где чувак чето тыкает в приложении. Видос по идее должен показывать, что мне нужно чинить, но обычно из него ничего не ясно
- Я копирую из заметок и отправляю вежливый комментарий, что-то типа "простите, извините, а можно чуть поточнее? Ожидаемое поведение? Реальное поведение? Устройство? Версия приложения? Добавьте меня в вашей проект"
- *ожидание/повторы вопросов с целью выжать максимум информации*
- Если пользователь продолжает конструктивный диалог, предоставляет нужную информацию, то приходится открывать IDE и пробовать воспроизводить. Если пользователю западло чето объяснять, то я выжидаю неделю, предупреждаю, что задача будет закрыта за недостатком вводных. И закрываю, ура, задача решена.
- В починке бага в таком проекте самое сложное – воспроизвести. Сценарии иногда поражают воображение: начни загрузку, включи выключи вайфай, войди в airplane mode, заблокируй телефон, разблокируй, перевени, останови загрузку и ты увидишь ОШИБКУ в одном случае из десяти! Пытаться починить этот ужас самому – лишиться личной жизни, мне за это недоплачивают. Поэтому обычно я выделяю себе час/два на попытки воспроизвести баг, если у меня не получается, перекидываю тестировщику с пометкой "не воспроизводится". Если и он не сможет воспроизвести, можно забить и закрыть.
- Иногда баг все же воспроизводится. После этого начинается поиск места, где же все таки ошибка. Довольно редко тут помогает логика и знание проекта, все чаще точки остановки дебаггера раставленные наугад по всему проекту. Иногда приходится разбираться в сложной бизнес логике, условях и ответах бэкенда. Лучший вариант: обнаружить, что косяк НЕ У НАС, а в соседней команде/на бэкенде. Можно кидаться задачкой в них и забывать про нее. Худший вариант: баг все таки на стороне iOS. Обычно это пара строк кода/лишнее условие, которое исправляется за несколько минут после обнаружения.
- Вношу правки, проверяю, что остальное приложение продолжает худо бедно работать. Пишу на починенный баг тест, если это представляется возможным. Создаю pull request через github, максимально подробно описываю проблему и решение, чтобы чуть облегчить жизнь моим последователям
- Жду пока мои правки посмотрят коллеги. Они должны отписать что-то вроде "вах, норм". Таким образом мы делим ответственность, если я накосячу, то нельзя будет ткнуть пальцем только в меня, виноваты все, а следовательно никто не виноват.
- После подтверждения от коллег pull request сливается в develop, CI отсылает сборку приложения с моими изменениями тестировщику. Он проверяет, что баг больше не воспроизводится. Если все ок, закрывает задачу, если нет, возвращает ее мне с пометкой "ты хуй, работай лучше"
- Такое перекидывание задач продолжается, пока она всем не надоест/не починится