Поскольку мы приближаемся к сезону жути, я хотел поговорить о самой страшной вещи, которая может появиться у любого программиста… о сообщении об ошибке. Когда вы прочесываете 300 строк кода, где вы вообще начинаете искать?!?? Cue выдергивание волос и стресс. Как известно любому кодеру, от новичка до профессионала, ошибка может означать часы поиска в вашем коде.

Как новичок, отладка была одной из последних вещей, о которых я думал. Однако отладка является одним из самых важных навыков, которые необходимо освоить, чтобы стать опытным программистом, и вам, скорее всего, придется заниматься отладкой в ​​тот или иной момент. Есть несколько разных инструментов для проверки кода на наличие ошибок; однако наиболее часто используются debugger и console.log().

Когда я впервые начал программировать, я избегал использования отладчиков, потому что не совсем понимал, где ставить точки останова. Однако, чем больше я писал, тем больше я начал определять, где совершаю больше всего ошибок, и начал использовать отладчики, чтобы найти свои ошибки.

Прежде чем углубляться в отладку, ознакомьтесь с рекомендациями, которые помогут вам избежать ошибок в коде, потому что предотвратить их намного проще, чем реагировать. Ознакомьтесь с этой статьей для получения более подробного списка, но мои ключевые выводы по предотвращению ошибок заключаются в следующем:

Следуйте стандартам кодирования. Стандарты кодирования призваны облегчить жизнь кодировщика. Например, const и let были созданы, чтобы вы не сталкивались с проблемами, возникающими в результате var, поэтому не используйте var для объявления переменных.

Сохраняйте простоту. Не усложняйте свой код — пишите его удобоваримыми, легко тестируемыми фрагментами. Не перекрывайте функции, структуры данных, условные операторы и т. д.

Проверяйте часто. Даже если ваш сервер работает без сбоев, найдите время, чтобы проверить его изнутри. Убедившись, что ваши структуры данных выглядят так, как вы хотите, вы можете уберечь себя от ошибок в дальнейшем.

Сохраняйте часто. Сохраняйте несколько версий своего кода, чтобы, если вы не можете найти ошибку, вы могли вернуться к версии, которая работала правильно. Продолжайте продвигать свой код на Github.

Обратите внимание: когда вы, коллега или товарищ по команде делаете ошибку, обратите на нее внимание. Та же ошибка может быть допущена снова, и вы сможете быстро выявить и исправить ее.

Теперь о реализации console.log()и отладчика. Я склонен делать ошибки при написании прослушивателей событий и запросов CRUD, поэтому я собираюсь показать вам, как я исправляю свои ошибки.

Обычно я использую отладчики только в том случае, если получаю предупреждение об ошибке просто для облегчения запуска моего кода на сервере, однако у меня всегда есть консоль. log()s замусорены в моем коде, просто чтобы убедиться, что все работает правильно.

Отладка прослушивателей событий и запросов CRUD:

Когда я впервые начал изучать прослушиватели событий в ванильном JavaScript, я никогда не использовал отладчики или console.log(), это было нормально, когда мы работали только с одним или двумя прослушивателями событий, но как только код усложнился, а файлы стали больше, они стали необходимостью. Например, этот прослушиватель событий находится в js-файле длиной 237 строк кода:

Если этот прослушиватель событий должен был выдать ошибку, трудно сказать, в чем может быть ваша ошибка — это прослушиватель событий, который не работает, или это запрос CRUD, или это другой прослушиватель событий в файле js?

Если вы добавите console.log(), когда вы изначально записываете событие перед добавлением результата события, это простой способ проверить, работает ли ваш прослушиватель событий. работает правильно.

(Совет: если вы включаете много console.log(), включите строку, которая поможет вам определить, на что они ссылаются, или закомментируйте их, когда закончите.)

Однако, как только вы добавите запрос CRUD, он вызовет повторную визуализацию страницы, которая сбрасывает консоль, поэтому добавление отладчика оказывается полезным:

Итак, в вашей консоли, когда вы нажмете кнопку «Добавить в библиотеку», вы увидите:

Когда код попадает в отладчик, визуализация приостанавливается. Как только вы нажмете кнопку паузы/воспроизведения, код будет выполняться до тех пор, пока вы не нажмете следующий отладчик. Это позволяет вам увидеть, что console.log() сообщает вам, что ваш прослушиватель событий работает до повторного рендеринга страницы:

(Если вы хотите узнать больше о кнопках управления отладчиком и добавить точки останова, не добавляя отладчик в свой код VS, я рекомендую просмотреть это видео YouTube .)

Теперь, когда у вас есть представление о том, как выглядит отладчик с работающим кодом, давайте посмотрим на тот же фрагмент кода, но с некоторыми ошибками.

Синтаксические ошибки как в прослушивателе событий, так и в CRUD-запросе обведены красным (обе эти ошибки я уже делал раньше¯\_(ツ)_/¯).

Взглянем на консоль:

При нажатии кнопки библиотеки отладчик никогда не запускается, что означает, что что-то не так с прослушивателем событий. Теперь, когда у вас есть представление о том, где произошла ошибка, вы можете более эффективно исследовать свой код. После изменения «щелчков» на «щелчки» прослушиватель событий заработает.

Теперь давайте рассмотрим отладчики вокруг CRUD-запроса:

Между этими двумя отладчиками посмотрите, что происходит с файлом json в VS Code:

POST по-прежнему создает новый объект, но он заметно отличается от других объектов в json — новый объект должен быть похож на предшествующий ему объект «Марк Твен». Также обратите внимание, что после того, как вы запустите последний отладчик, ваша консоль вернет ошибку:

Теперь, когда вы знаете, где находится эта ошибка, вы можете проверить свою работу и исправить ее. Наконец-то вы устранили все свои ошибки и вам не пришлось проверять 237 строк кода! Хотя добавление этих console.log() и отладчиков иногда может показаться утомительным, оно определенно может сэкономить тебя от тех моментов, когда дергают за волосы.