Так, сегодня хочу поговорить с вами о втором самом важном навыке кодеров. Первый - это гуглить, естественно.
Но вот нашли вы подходящее решение, вставили его в проект. А оно не работает. Что делать? Правильно - искать ошибку и фиксить её. Так что умение найти ошибку - одно из самых важных. Разрабатываете свой продукт, или фиксите чужой, или сидите на поддержке какого-либо проекта - вам все равно придется сталкиваться с поиском ошибок. Научитесь это делать - жизнь станет проще.
С чего начать. К счастью, вы не пишите на машинном языке. Почти все инструменты уже созданы до вас, в том числе и языки программирования. И эти создатели позаботились о вас, добавив подсказки о том, что же могло пойти не так. Так что в первую очередь, абсолютно всегда, смотрите на сообщения в вашем интерфейсе. Для js это может быть вкладка Console в браузере, для всяких инструментов, по типу webpack, терминал, где вы его запустили, для некоторых языков - компиляторы и тд. Все они пытаются облегчить вашу судьбу и максимально подробно сказать что не так. В пределах их возможностей, конечно 🙂
Реальный пример, который мне присылали, сможете найти в чем проблема? Скрин: https://prnt.sc/yp8cuv
Дальше уже смотрим на указанную строку с проблемой, с какими участками кода она связана и пытаемся фиксить проблему. Но это уже другой разговор.
Дополнительной опцией здесь я бы включил навык чтения логов. Скорее всего вы видели уже фразу: to see full information, check log file… Тут уже необходима усидчивость, так как дело это не простое на первый взгляд. Но дает целую кучу информации. Например, логи серверов, если что-то идет не так: https://prnt.sc/yp9334
А вот если нет никаких сообщений? Код думает, что все в порядке, вы так и задумывали. В таком случае, вам нужно научиться проверять параметры, которые вы лично передаете коду и логику работы. Первый вариант довольно прост: это может быть селектор с опечаткой, не та переменная и тд. Это не должно занять много времени.
А вот с логикой работы будет сложнее. Я всегда сторонник того, чтобы код читать по строкам, даже если вы думаете, что понимаете его на 100%. Неожиданно может оказаться, что где-то логика дает сбой (например цикл в цикле).
В этих двух случаях хорошо будет научится работать с дебаггером. Он есть почти везде 😏 В том же js вы можете увидеть что происходит на каждой строке во время выполнения: https://prnt.sc/ypg52h Отследить изменения будет куда проще.
Тут вы меня спросите, а если косяк в верстке или css-стилях?
Верстка: для начала отформатируйте код, чтобы он выглядел красивой «елочкой». Тот же плагин Beautify вам в помощь. Это позволит вам отследить все несостыковки по незакрытым тэгам. Не получилось? Прогоняем верстку через валидатор: https://validator.w3.org/
Он позволяет не только отслеживать невалидные код, но и найти косяки. Это же одно и тоже 🙂
Стили: смотрим в инспекторе кода, применяются ли они для этого класса. Проверяем опечатки и специфичность селекторов. Обычно тут все упирается в опечатки 🙂
Хорошо, даже если не получилось найти ошибку и у вас есть человек, который посмотрит ваш код, то как лучше взаимодействовать? Не переживайте, это нормально в начале пути, особенно во время обучения. Но и в будущем, в компаниях вам очень пригодятся эти правила.
Первое: присылайте код. Не скриншоты, не фотки, не отдельные куски кода. Лучше залить проект на GitHub, облачное хранилище или обменник. Поверьте, смотреть реальный код в разы проще. Можно сразу не только поправить ошибку, но и найти новые 🙂
Второе: четко объясняйте что не получается. Блок Х не реагирует на событие У при обстоятельствах Z. Отправьте полный скрин ошибки, которая у вас возникает в консоли.
Третье: напишите ваши условия, в которых вы работаете. Браузер, операционная система, версия node.js, других пакетов или плагинов и тд. - все это очень помогает разобраться. Если посмотреть профессиональные отчеты о багах - то эта информация обязательна.
Помните, что все приходит с опытом и все через это проходили. Поменьше вам ошибок в коде и успехов в дебаге
#полезности
Но вот нашли вы подходящее решение, вставили его в проект. А оно не работает. Что делать? Правильно - искать ошибку и фиксить её. Так что умение найти ошибку - одно из самых важных. Разрабатываете свой продукт, или фиксите чужой, или сидите на поддержке какого-либо проекта - вам все равно придется сталкиваться с поиском ошибок. Научитесь это делать - жизнь станет проще.
С чего начать. К счастью, вы не пишите на машинном языке. Почти все инструменты уже созданы до вас, в том числе и языки программирования. И эти создатели позаботились о вас, добавив подсказки о том, что же могло пойти не так. Так что в первую очередь, абсолютно всегда, смотрите на сообщения в вашем интерфейсе. Для js это может быть вкладка Console в браузере, для всяких инструментов, по типу webpack, терминал, где вы его запустили, для некоторых языков - компиляторы и тд. Все они пытаются облегчить вашу судьбу и максимально подробно сказать что не так. В пределах их возможностей, конечно 🙂
Реальный пример, который мне присылали, сможете найти в чем проблема? Скрин: https://prnt.sc/yp8cuv
Дальше уже смотрим на указанную строку с проблемой, с какими участками кода она связана и пытаемся фиксить проблему. Но это уже другой разговор.
Дополнительной опцией здесь я бы включил навык чтения логов. Скорее всего вы видели уже фразу: to see full information, check log file… Тут уже необходима усидчивость, так как дело это не простое на первый взгляд. Но дает целую кучу информации. Например, логи серверов, если что-то идет не так: https://prnt.sc/yp9334
А вот если нет никаких сообщений? Код думает, что все в порядке, вы так и задумывали. В таком случае, вам нужно научиться проверять параметры, которые вы лично передаете коду и логику работы. Первый вариант довольно прост: это может быть селектор с опечаткой, не та переменная и тд. Это не должно занять много времени.
А вот с логикой работы будет сложнее. Я всегда сторонник того, чтобы код читать по строкам, даже если вы думаете, что понимаете его на 100%. Неожиданно может оказаться, что где-то логика дает сбой (например цикл в цикле).
В этих двух случаях хорошо будет научится работать с дебаггером. Он есть почти везде 😏 В том же js вы можете увидеть что происходит на каждой строке во время выполнения: https://prnt.sc/ypg52h Отследить изменения будет куда проще.
Тут вы меня спросите, а если косяк в верстке или css-стилях?
Верстка: для начала отформатируйте код, чтобы он выглядел красивой «елочкой». Тот же плагин Beautify вам в помощь. Это позволит вам отследить все несостыковки по незакрытым тэгам. Не получилось? Прогоняем верстку через валидатор: https://validator.w3.org/
Он позволяет не только отслеживать невалидные код, но и найти косяки. Это же одно и тоже 🙂
Стили: смотрим в инспекторе кода, применяются ли они для этого класса. Проверяем опечатки и специфичность селекторов. Обычно тут все упирается в опечатки 🙂
Хорошо, даже если не получилось найти ошибку и у вас есть человек, который посмотрит ваш код, то как лучше взаимодействовать? Не переживайте, это нормально в начале пути, особенно во время обучения. Но и в будущем, в компаниях вам очень пригодятся эти правила.
Первое: присылайте код. Не скриншоты, не фотки, не отдельные куски кода. Лучше залить проект на GitHub, облачное хранилище или обменник. Поверьте, смотреть реальный код в разы проще. Можно сразу не только поправить ошибку, но и найти новые 🙂
Второе: четко объясняйте что не получается. Блок Х не реагирует на событие У при обстоятельствах Z. Отправьте полный скрин ошибки, которая у вас возникает в консоли.
Третье: напишите ваши условия, в которых вы работаете. Браузер, операционная система, версия node.js, других пакетов или плагинов и тд. - все это очень помогает разобраться. Если посмотреть профессиональные отчеты о багах - то эта информация обязательна.
Помните, что все приходит с опытом и все через это проходили. Поменьше вам ошибок в коде и успехов в дебаге
#полезности