От переводчика: Джордж Алан Хеймел в своей статье делится собственным опытом и говорит о том, чем должен руководствоваться разработчик в процессе отладки.
Современный инструментарий разработчика весьма обширен, так что выбрать есть из чего — инструментов отладки. Многие из них автоматизированы, но, к сожалению, пустить дебагинг на самотек не получится — ручной работы все еще много. Иногда кажется, что проблемы просто не должно быть, это невозможно, все должно работать. Но не работает. Чтобы не тратить лишние нервные клетки и время, я вывел для себя простые правила отладки, которыми и пользуюсь. Думаю, кто-то может посчитать их спорными. Тем не менее, мне они помогают.
Skillbox рекомендует: «Мобильный разработчик PRO».
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Правило 1. Всегда есть причина
Несмотря на утверждения вроде «Это невозможно», «Оно не должно работать так», «Нет причины, чтобы этот код не работал».
Причина есть всегда, будь то неправильно работающий код или ошибки при компиляции. Всегда. Даже если чекер говорит, что все хорошо. Иногда мы слишком глубоко погружаемся в код, теряя общую картину. Большинство обычных или веб-приложений представляют собой сложную структуру. Все они включают множество элементов. Иногда слишком много, так что мы можем допустить ошибку в одном из них и забыть или не заметить этого.
Отступите, сделайте глубокий вдох. Затем посмотрите на код снова. Не надейтесь лишь на инструменты. Используйте и логику. Подумайте, как текущий элемент, над которым вы работаете, влияет на все остальное. В большинстве случаев ошибка относится к классу ПМСИС (проблема — между стулом и столом).
И ради всего святого, когда вы исправляете что-то, не правьте сразу десять потенциальных ошибок. В противном случае вы запутаетесь, найти реальную ошибку будет крайне сложно. Порой отладка требует немного терпения: вносите небольшие изменения шаг за шагом. Будьте методичны и точны, как скальпель, а не как дробовик.
Правило 2. RTFM & WTFV
Большинство разработчиков — умные люди. Иногда даже слишком умные, во вред себе. Все мы думаем, что не нуждаемся в базовых туториалах, можно ведь сразу начать изучение продвинутых вещей.
Да, конечно, в некоторых случаях проблемы нет, кроме того, мы учимся по мере реализации различных проектов. Но может возникнуть ситуация, когда вы несколько недель будете заниматься крупным и сложным проектом, а затем окажется, что все основано на неверной предпосылке — ошибке, которая делает невозможной дальнейшую работу. Это может относиться к фреймворку, языку, инструменту. Вы просто потеряете время.
Поэтому усвойте правило, которое на английском языке звучит, как Read the F***ing Manual or Watch the F***ing Video (отсюда и сокращения в подзаголовке).
Иногда вы просто пропускаете критически важный момент, мелочь, необходимую для работы. Необходимо хотя бы мельком ознакомиться с базовой информацией о продукте, который вы используете. В моей практике было много случаев, когда разработчики срывали сроки из-за пробелов в знаниях о языке или инструментах. И это были неплохие специалисты, — просто они перепрыгивали сразу в конец книги, упуская важные слова автора в начале.
Новые фреймворки появляются едва ли не каждый день, языки или их новые версии выходят также с завидной регулярностью. Чтобы эффективно использовать такие инструменты, мы должны понимать, как они работают.
Правило 3. Пожалуйста, используйте правила 1 и 2
Так, вы прочитали статью и начали работать. Спустя пару часов встречаете мануал, который важен для нашей работы, и… пропускаете его. Нет, так не пойдет, воспользуйтесь правилами выше. Никто не говорил, что будет легко.
Правило 4. Изучайте изменения
В процессе работы случается так, что инструменты, которые вы используете, изменяются. Если вы веб-разработчик, это утверждение особенно актуально — JavaScript-фреймворки, библиотеки и инструменты очень часто изменяются и обновляются.
К счастью, не только вы, но и многие другие разработчики используют эти же инструменты. Информацией о проблемах и наработках они делятся на соответствующих ресурсах вроде Experts Exchange и StackOpen или на профильных форумах.
Ищите информацию о своей проблеме или изменениях в инструменте, пока не найдете. Если ничего нет, перечитайте правило № 1.
Правило 5. Отдохните и начните с самого начала
В некоторых случаях мы действительно не видим леса за деревьями. Погружение в код на долгие часы истощает нас как умственно, так и физически. Если вы прошли по своему коду уже раза три и до сих пор не нашли причины ошибки, — самое время дать отдохнуть своему .
В некоторых случаях простая прогулка на свежем воздухе наводит на новую мысль и помогает сразу же найти проблему. Иногда нет, но нервотрепка, агрессия или отчаяние — не лучшие помощники в нашем деле.
Просто не смотрите на экран. Поговорите с коллегой, посидите в тишине, ведь шум действует негативно. Перекусите, в конце концов. Если время позволяет, просто поспите, забудьтесь крепким и глубоким сном. Иногда мне удавалось найти ответ на мучающий меня вопрос после сна.
Очистите свою голову от всей мишуры и мусора предыдущих попыток найти ошибку и посмотрите на проблему с неожиданной стороны.
Ну а затем… да, вы верно угадали. Возвращаемся к правилу № 1.
Skillbox рекомендует:
- Практический курс «Профессия веб-разработчик».
- Онлайн-курс «Профессия Frontend-разработчик».
- Практический годовой курс «PHP-разработчик с нуля до PRO».
Автор: fokus-lop
