Как экономить нервы и время при отладке кода
Привет, Хабр! Меня зовут Евгений, и я решил посвятить свою первую статью на Хабре одной из важнейших и интересных тем — поиску багов в программах. Цель этой статьи максимально коротко и понятно посвятить читателей в отладку.
Мне очень нравится играть в детектива и с азартом выяснять, как работает программа. К тому же я люблю слушать истории моих друзей и коллег по решению проблем и рассказывать о том, насколько иногда был тяжел путь к поиску верного решения. Однако профессиональным программистам необходимо беспокоиться об интересе бизнеса, а бизнесу прежде всего важно, чтобы решение было найдено в ближайшее время и чтобы фикс бага не добавил новых проблем.
Раньше я, наверное, как и многие программисты пытался пофиксить баг сразу как только видел сообщение об ошибке. Но это далеко не всегда правильный путь, так как часто за маленькой ошибкой стоит нечто большее. Нужно решать проблему, а не просто бороться с симптомами: за одной ошибкой может скрываться следующая и следующая.
Сбор информации
Прежде чем исправить баг, нужно понять, где он прячется. В идеальном мире сообщение об ошибке должно предшествовать ее исправлению, иначе в дальнейшем будет сложно понять, что ошибка была исправлена.
Сбор информации для разных проблем в разных компаниях может сильно отличаться. Поэтому я предложу несколько обобщенных рекомендаций:
Спросить. Довольно часто ошибки вызваны добавлением нового кода, что значительно сужает круг, где стоит искать проблему.
Опираться прежде всего на код. Верить на 100% можно только коду. Документация может содержать ошибки и быть устаревшей. Логирование пишут те же программисты, что и делают баги в коде. Тестировщики и аналитики — тоже люди. И лишь программа четко выполняет логику, которая была заложена.
Поиск всех ситуаций, вызывающих ошибку. Если есть возможность, то лучше потратить время на детальный анализ всех ситуаций, где возникает данная ошибка, чтобы в полной мере понять, что она из себя представляет.
Методы отладки
Очень важно понять не только, где возникла ошибка, но и почему она возникла. Это, как правило, занимает больше времени, но помогает исправить проблему целиком, а не лечить симптомы.
Прислушаться к естественному
Многие люди считают, что естественная среда обитания программистов, это солнечные пляжи полные вкусного смузи и двойного латте на кокосовом молоке, однако, на самом деле большую часть времени они обитают в своей среде разработки со статическими анализаторами и инструментами для профилирования программ.
И они не были бы программистами, если бы не оптимизировали все, что только можно оптимизировать. И благодаря их труду с большой вероятностью среда разработки подсветит программистам те части кода, которые являются недопустимыми, и предложит варианты их исправления.
Если вы не являетесь тем счастливчиком, работа которого сделана средой разработки, то не расстраивайтесь: вы еще можете им стать. Ведь еще существует множество встроенных инструментов для отладки и бессчетное количество плагинов для проверки кода на качество. Возможно именно сейчас пришло время их установить и попробовать, чтобы в полной мере насладиться процессом естественного преобразования логики в код.
Наугад
Лучший метод, если хочется, чтобы мир компьютерных наук был полон магии и демонических компьютеров. Однако решение проблемы данным методом займет много времени и, скорее всего, вы не докопаетесь до истинной причины ее возникновения, так как не осознаете саму суть проблемы.
Научный метод
Классический научный метод состоит из следующих пунктов:
Сбор данных;
Формирование гипотезы;
Разработка эксперимента с целью подтвердить или опровергнуть гипотезу;
Проведение эксперимента;
Повторение в случае необходимости.
К определению причины появления ошибки можно подойти эмпирически, собирая как можно больше данных о самой ошибке, и теоретически, анализируя логику работы программы.
В процессе рассуждений можно использовать один из двух способов: индукцию, как рассуждение от частного к общему, и дедукцию, как рассуждение от общего к частному.
Для достижения наилучшего результата рекомендуется комбинировать данные подходы.
Если ошибка является настолько большой, что ее невозможно осознать, то рекомендую использовать инкрементный подход, который состоит в нахождении наилучшее промежуточного решения проблемы и его возможном откате, если на следующем этапе понимания проблемы были получены данные, которые не сходятся с предыдущими решениями.
Метод грубой силы
Самый надежный метод, но для больших программ может стать невероятно долгим. Если предыдущие методы заняли много времени и не принесли желаемого результата, то решение методом грубой силы будет хорошим решением.
Его суть состоит в ручном отслеживании каждого шага программы, проверки кода строчка за строчкой в поисках ошибки. В данном процессе также можно воспользоваться временным «выбрасыванием» подозрительных фрагментов программы с возможным перепроектированием и переписыванием этих частей с нуля.
Парное программирование
Иногда, объясняя проблему другому человеку, можно найти ошибку в своих суждениях или заметить деталь, которая вечно ускользала, или даже получить совет о том как лучше решить сложившуюся проблему.
Когда нет возможности обратиться за помощью к другим программистам, то можно воспользоваться «методом уточки». Суть метода заключается в задавании вопроса воображаемому собеседнику так, будто бы он сможет ответить на него, переводя «поток сознания» в сформулированную мысль, которая позволит более осознанно взглянуть на проблему.
Можно даже обратиться к ИИ, чтобы вместе порассуждать с ним. Этот вариант, как и предыдущие, заставит сформулировать вопрос, но ИИ дополнительно предложит варианты потенциального решения. Однако нужно помнить, что ИИ очень любит искажать факты для обоснования своего решения, поэтому было бы хорошо иметь немного знаний в промт‑инжиниринге. К тому же стоит помнить, что не стоит «кормить» ИИ кодом вашего проекта, если это является недопустимым со стороны вашей компании. Для более удобного использования ИИ создано много плагинов для среды разработки.
Вывод
Отладка кода — это краеугольный камень разработки программного обеспечения, ведь именно на этом этапе выясняются все слабые стороны разработчиков и практик написания кода, которые они выбрали. Невозможно не допускать ошибки, но можно сэкономить много ресурсов при их исправлении.
При отладке рекомендуется комбинировать подходы, которые были упомянуты в этой статье. При решении сложных задач по возможности желательно делать заметки о результатах, ведь даже неправильный результат попытки осознать ошибку может много сказать о потенциальном решении проблемы.
На написание данной статьи меня вдохновили книги «Совершенный код» Стива Макконнелла, «Программист‑прагматик» Эндрю Ханта, несколько историй дядюшки Боба и свой личный опыт, полученный при разработке и общении с коллегами и друзьями.
