«Я не люблю жутких ползучих жуков, но программные жучки — совсем другая история. Я с удовольствием охочусь и убиваю особенно мерзких программных жучков. Здесь я расскажу вам о том, как я подхожу к решению проблемы с ними. Многое из моего процесса покажется вам как бы очевидным, но вы удивитесь, увидев, как много людей бегают по кругу, пытаясь исправить хитрые баги. Осознанное следование описанному ниже процессу может помочь вам сохранять спокойствие.
И да, эти действия покажутся вам знакомыми, если вы вспомните уроки биологии в средней школе. Помните, как вам снова и снова повторяли «научный метод, научный метод»? Когда вы писали бесчисленные лабораторные работы и отчеты. Вы же помните? Такое:
- Постановка вопроса (то есть проблемы)
- Формирование гипотезы
- Планирование эксперимента
- Регистрация данных и наблюдений
- Возвращение к шагу 2 (при необходимости)
- Отчет (выводы)
Сформулируйте вопрос или проблему
Первый шаг всегда заключается в том, чтобы сформировать у себя осознанное понимание того, что нужно исправить или решить. Формирование краткого вопроса или формулировки проблемы поможет вам с самого начала точно определить цель.
Вопрос в компьютерных науках может звучать так: «Почему фича X в программе делает Y, когда пользователь делает Z?». Зачастую это можно сделать в баг-репорте или в тикете бэклога.
Еще одна важная часть этого шага — собрать и задокументировать всю доступную информацию. Есть ли у вас надежные шаги по воспроизведению? Какие пользователи пострадали? Как давно это происходит? Какие части приложения затронуты проблемой?
Сформулируйте гипотезу
Как только вы соберете как можно больше информации, используйте ее для создания гипотезы, или предсказания того, что может быть причиной бага. Возможно, у вас есть очень какие-то догадки. Может быть, они расплывчаты, но это не страшно. Например, можете выдвинуть такую гипотезу: «Я думаю, что пользователи неожиданно выходят из системы с ошибкой, потому что срок действия их токенов доступа истекает раньше, чем ожидалось». А может быть, нужно начать с более общего, например: «Я думаю, что просроченный сетевой запрос может привести к неожиданному выходу пользователя из системы».
Обязательно запишите свою гипотезу. К ней будет полезно вернуться позже, чтобы не тратить время на повторение одних и тех же тестов.
Запланируйте эксперимент
Существует множество экспериментов, которые могут проверить вашу гипотезу. Написание автоматизированных тестов, использование отладчика, наблюдение за сетевыми инструментами разработчиков или даже просто добавление log(«here») в ключевых точках — все это вполне допустимые варианты. Но, планируя тестирование, не забывайте о своей гипотезе. Четко поставленная цель эксперимента сделает вашу охоту за багами более упорядоченной.
Цель этого шага не в том, чтобы исправить баг. Вы просто хотите определить степень достоверности вашей гипотезы. Вы не должны вносить никаких серьезных изменений в код, потому что мы хотим использовать эти тесты, чтобы понять реализацию как есть, в текущем ее состоянии. Если ваш эксперимент приведет вас прямо к решению, это замечательно, но в случае особо сложных багов вы должны спокойно относиться к нескольким неудачным экспериментам подряд, прежде чем найдете решение.
Зафиксируйте полученные данные и свои наблюдения
После того как эксперимент поможет вам разобраться в гипотезе, запишите, что вы узнали. Вернитесь к тому месту, где вы записали свою гипотезу, и отследите, что вы узнали. Возможно, это даже поможет написать, что вы сделали, чтобы прийти к выводу. Не волнуйтесь, если ваш эксперимент опровергнет гипотезу. В большинстве случаев так и будет, и это просто означает, что вы стали на шаг ближе к поиску настоящего решения.
Отслеживание и фиксирование этих моментов — большое преимущество при передаче работы другому сотруднику или откладывании ее на потом. Если появится более приоритетная фича, и вы не сможете вернуться к этому багу в течение нескольких дней, вы будете благодарны себе за то, что не пришлось начинать всё с начала. Если коллеге придется взять эту часть работы на себя, ваши заметки станут для него отличной точкой входа.
Повторите процесс
Теперь вы лучше понимаете, что происходит. Используйте эту информацию для формирования новой гипотезы и повторите процесс. Гордитесь неудачными экспериментами: каждая неудача — это еще один уголок приложения, который вы исключили и очистили, там нет багов.
Самое сложное в этом процессе — если вы чувствуете, что не можете выдвинуть новую гипотезу. Если вы попали в такую ситуацию, попробуйте рассмотреть ситуацию как бы на расстоянии. Пусть приложение будет «черным ящиком»; наблюдайте за входящими действиями и выходящими из него ошибками. Затем постепенно уменьшайте «черный ящик» до более мелких частей приложения.
Напишите отчет
Если вы докажете, что ваша гипотеза верна, у вас должно быть достаточно информации, чтобы сузить область неисправного кода. После того как эти баги исправят, самое важное, что вы можете сделать — отчитаться перед командой о том, что было не так, как это было исправлено, и о любых других интересных находках, которые вы сделали по пути.»