И это всегда помогает мне методично решать проблему.
Ошибки в исходном коде - это нормально. Это борьба, с которой каждый программист сталкивается ежедневно. Однако когда мы находимся в начале нашего приключения в программировании, ошибка кода может вызвать у нас панику. Я справился с этим чувством, создав свою собственную систему отладки кода. Я до сих пор им пользуюсь, и хочу поделиться с вами.
Я постоянно пытаюсь улучшить способ отладки кода. На данный момент это то, что у меня работает. Я рекомендую вам протестировать приведенный ниже совет и найти свои собственные шаги для лучшей отладки.
Универсальные ступени
Во-первых, я хочу познакомить вас с некоторыми универсальными шагами, которым вы можете следовать. Они не связаны с тем, отображается ли ошибка в консоли или код не работает должным образом.
Проверяю, что сохранил все изменения.
В самом начале я проверяю, что я сохранил изменения во всех файлах, над которыми работал. Ошибка могла быть связана с тем, что я что-то изменил в одном файле, использовал в другом и не сохранил изменения.
В редакторе или IDE, в которых вы работаете, обязательно есть индикатор, показывающий, сохранен файл или нет. В Visual Studio Code это белая точка рядом с именем файла (на верхней панели) и полупрозрачная точка рядом с именем папки, в которой находятся несохраненные файлы (на виде сбоку для всех файлов).
Проверяю, работаю ли я над правильной версией кода
Особенно полезно, когда вы работаете в команде, поэтому с кодом разбираетесь не только вы. Я всегда проверяю, внесены ли последние изменения, прежде чем продолжить отладку. Ошибки в коде могут быть из-за того, что у меня локально устаревшая версия.
Обновляю страницу / перезапускаю проект.
Совет типа «пожалуйста, выключите и снова включите». Как бы глупо это ни звучало, во многих случаях это действительно помогает. Веб-сайт или проект могут не работать, потому что я ищу устаревшую устаревшую версию. Даже если вы думаете, что перед вами нужная версия, стоит повторно включить предварительный просмотр в браузере или перезапустить проект. При желании в этом случае вы также можете очистить данные браузера, будь то файлы cookie, локальное хранилище или хранилище сеанса (если, конечно, вы знаете, что ваш веб-сайт или проект основан на них).
Я проверяю, хорошо ли проект «уволен».
Что это значит для меня? Я проверяю, правильно ли построен проект и правильно ли прикреплены все файлы. Импортируются ли необходимые файлы. Я убеждаюсь, что Интернет работает (если этого требует проект) и что я нахожусь в хорошей сети. На мой взгляд, стоит составить список вещей, которые необходимо выполнить, чтобы проект вообще заработал. Это действительно экономит время, потому что иногда мы устаем на час из-за какой-то проблемы, и оказывается, что Wi-Fi переключился, и поэтому у нас есть ошибка.
Ошибка в консоли или терминале
Теперь давайте посмотрим на ошибку, которая появляется в консоли или терминале. Может случиться так, что приложение или сайт вообще не строятся (но это не является обязательным условием). А что я тогда делаю?
Я внимательно прочитал сообщение об ошибке.
Это кажется очевидным, но определенно не очевидным. У меня самого была проблема, что я не сосредотачивался на его содержании, когда увидел красную доску. И в подавляющем большинстве случаев мы можем вывести из содержания ошибки, что произошло. Конечно, тоже будут ошибки типа «вы ошиблись» и ничего больше, и тогда вам придется немного подумать. Если в сообщении, которое вы видите, есть какое-либо содержание, внимательно прочтите его.
Это действительно очень важно. Я не раз проводил семинары для новичков и знаю, что легко запаниковать, если вы видите ошибку, если вы не имеете отношения к коду. Мне довелось получить скриншоты с ошибками, в которых было четко написано, что делать, чтобы избавиться от этой ошибки. И люди, приславшие мне скриншоты, спрашивали, что делать. Я знаю, что это приходит со временем, поэтому я сразу же проинформировал вас - прочтите это спокойно и задайтесь вопросом, какие шаги должны быть следующими.
Я следую инструкциям в сообщении об ошибке.
Сообщение об ошибке, которое вы видите, может подсказать, что нужно сделать, чтобы устранить ошибку. Стоит попробовать, а не изобретать велосипед. Также может быть, что ошибка, которую вы видите, уже случилась с вами раньше, и вы знаете, как с ней бороться. Я хочу сказать, что в сообщении может быть сказано, например, что переменная не определена. Вы сразу понимаете, что ее нужно определить или что вы допустили / допустили ошибку в названии, потому что у вас определенно определена эта переменная.
Я пытаюсь найти строку / часть кода, вызывающую ошибку.
Если это явно не упоминается в сообщении об ошибке, я пытаюсь найти часть кода, на которую может повлиять эта ошибка. Обычно я комментирую отрывки и смотрю, обнаруживается ли ошибка. Я пытаюсь привести сюда либо отображение очередной ошибки, либо исчезновение текущей ошибки. Да, ошибка, отличная от той, с которой мы боремся, определенно является шагом вперед, как будто это не звучит искаженно. Когда у меня есть затронутая часть кода, я тщательно анализирую ее и пробую разные вещи, которые соответствуют тем, что в следующей части (то есть, что я делаю непосредственно с кодом).
Код не работает должным образом
Теперь, пожалуй, более частый случай, т.е. код работает, у нас нет ошибок, но не все так, как должно. А что я тогда делаю?
Я пытаюсь найти последнюю версию кода, которая хорошо работает
Работает не только то, как мы работаем в команде, но и то, как мы действуем в одиночку. Если данная функция работала и теперь не работает, я нахожу последнюю версию кода, которая была в порядке. Я проверю, что изменилось с тех пор. Также учитываю установленные пакеты или библиотеки.
Если смогу выявить изменения - удаляю их и проверяю, действительно ли помогает. Если да, то я анализирую, что именно делает код, ищу ошибки в логике. Одним словом - пытаюсь заставить работать.
Если мне сложно найти последнюю рабочую версию кода (а я знаю, что это было), я использую команду git bisect. Это позволяет вам вернуться, например, на несколько месяцев, пометить последующие коммиты как хорошие или плохие и, таким образом, посмотреть, какая фиксация привела к ошибке в нашем коде.
Я ищу минимально возможный фрагмент кода, ответственного за ошибку.
Моя цель - сначала найти файл, а затем функцию или метод, желательно строку, из-за которой код не работает должным образом. Я использую console.log, чтобы проверить, до какой степени все в порядке. Обычно я выполняю ввод и вывод console.log (проверяю, какие данные пришли, что вернули). При использовании console.log я всегда описываю то, что показываю, чтобы в консоли не появлялась стена журналов, которые мне ничего не говорят.
Я знаю, что вы также можете использовать отладчик в этой ситуации, но я плохо владею этим инструментом, поэтому я не использую его часто. У меня есть планы хорошо его освоить, поэтому я с радостью приму все советы по поводу отладчика.
Я составил план действий.
Здесь мы уже переходим к очень подробным действиям, поэтому я думаю, что нет смысла описывать их подробно, потому что многое зависит от того, что я хочу получить, и, конечно же, от того, какие именно ошибки у меня есть в коде. Когда я могу найти строку или фрагмент ошибки, я составляю план действий.
Я имею в виду не какие-то долгосрочные планы, а подход к проблеме с головой. То есть - я предполагаю, например, что я попытаюсь добавить console.login все методы, запущенные в данном фрагменте, я проверю, все ли они получают и возвращают соответствующие данные, я анализирую структуру данных.
Я записываю логику на листке бумаги.
Еще я часто записываю логику работы кода на листке бумаги. Когда проблема сложная, я перечисляю, что должен делать код, и проверяю, происходит ли это. Многое зависит от ошибки, с которой я сталкиваюсь, когда работаю со многими компонентами, файлами или классами.
Я проверяю порядок загрузки файлов, если нет проблем, связанных с неправильным порядком загрузки. Я записываю на листе бумаги, в каком порядке они должны быть и что именно они делают, чтобы потом мне было легче отслеживать, что происходит в запускаемой программе.
Я создаю новую ветку и фиксирую изменения как можно чаще.
Прежде чем я начну вносить изменения в код, который не работает, создайте новую ветку (ветку) в Gita. Благодаря этому я всегда могу вернуться к исходной ветке, не отменяя внесенные изменения. Часто я могу понять слишком много, пытаясь решить проблему, и у меня появляется много новых ошибок. Когда я попадаю в такую ситуацию, я могу отказаться от внесенных мной изменений и начать все сначала.
В то же время я стараюсь фиксировать вносимые мной изменения как можно чаще. Я описываю, что именно я изменил. Затем я смотрю, что пробовал, отображая список коммитов. У меня также есть возможность вернуться к выбранной фиксации, если мне нужно.
И так далее.
Ошибки кода - это своего рода нескончаемая история. Часто что-то выходит из строя, и нам приходится с этим бороться. Вышеупомянутые методы не являются надежными, но они помогают мне структурировать отладку. Они дают мне ощущение, что я контролирую процесс, и они дают мне немного меньше суеты, когда код не работает.
Излишне говорить, что отладка лучше всего практикуется с помощью отладки. И когда вы находитесь в начале пути с кодом, стоит как можно скорее попрактиковаться на практике. Лучше создавать собственные проекты!
