Старший разработчик посмотрела на мой экран ровно семь секунд. Затем сказала: «В массиве зависимостей useEffect отсутствует userId«.

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

Я чувствовал себя профаном. Затем полюбопытствовал: «Как вы это поняли?»

Она пожала плечами: «Я сама совершала эту ошибку. Раз пятьдесят. Теперь просто знаю, где искать».

Этот случай изменил мое представление о том, что значит быть разработчиком. Я относился к отладке как к режиму провала — к тому, чем занимаешься, когда твоя настоящая работа (написание кода) идет не так, как надо. Она относилась к этому как к самой настоящей работе. И была права.

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

Писать код — это просто

Будем честны: написание кода — самая простая часть разработки. У вас есть спецификация, вы знаете синтаксис и печатаете. Компьютер делает именно то, что вы ему говорите — и в этом вся проблема, потому что вы часто говорите ему не то, что нужно.

Каждый разработчик может написать код, работающий изолированно. Сложность заключается в написании кода, который работает в реальной системе, с реальными данными, реальными пользователями и реальными крайними случаями, которые  невозможно предвидеть. Разница между младшим и старшим разработчиком не в количестве написанных строк. Разница в том, сколько строк было отлажено.

Когда вы следуете туториалу, все работает, потому что путь проложен. Когда создаете что-то оригинальное, постоянно находитесь на неизвестной территории. Карты не существует. Отладка — процесс ее создания.

Отладка позволяет понять, как все работает на самом деле

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

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

Каждая устраненная вами ошибка расширяет ваше представление о системе. Чем больше вы отлаживаете, тем больше понимаете. Чем больше понимаете, тем меньше ошибок допускаете. Это полезный цикл — но только если  воспринимать отладку как обучение, а не как провал.

Навыки отладки универсальны

Технологии могут измениться. Фреймворки, освоенные сегодня, через пять лет устареют. Но навык систематически изолировать проблему, формулировать гипотезы, тестировать их и находить первопричины применим везде.

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

  1. Точно зафиксируйте сбой. Что на самом деле произошло? Что должно было произойти?
  1. Изолируйте переменные. Что изменилось? В чем разница между рабочим и нерабочим состоянием?
  1. Выдвиньте гипотезу о причине. Исходя из того, что вы знаете, какое объяснение наиболее вероятно?
  1. Проверьте гипотезу целенаправленным экспериментом.
  1. Повторяйте, пока не найдете причину.

Этот процесс работает, отлаживаете ли вы JavaScript в браузере, Python на сервере или SQL в базе данных. Это не технические знания. Это образ мышления.

Настоящая отладка — систематическая работа, а не хаотичный процесс.

Новички отлаживают наугад. Изменяют что-то, затем проверяют, работает ли, потом изменяют что-то еще. Это отладка наудачу, и она выматывает.

Системный подход выглядит иначе:

  • Прочитайте сообщение об ошибке. Сообщения об ошибках — не наказание. Это компьютер точно сообщает вам, что именно не так. Приучайтесь читать эти сообщения.
  • Добейтесь стабильного воспроизведения. Если не можете уверенно воспроизвести ошибку, не сможете узнать, когда она исправлена.
  • Проверьте свои предположения. Что из того, что вы считаете правдой, может оказаться ложью? Отсутствие userId в массиве зависимостей было предположением о том, как работает React.
  • Действуйте по принципу «разделяй и властвуй». Проведите бинарный поиск по коду. Закомментируйте половину. Если ошибка осталась, она в другой половине. Сужайте круг.
  • Объясните проблему кому-то другому. Отладка методом утенка (rubber duck) работает, потому что формулировка проблемы заставляет вас мыслить ясно.
  • Делайте перерывы. Пялиться в один и тот же код часами контрпродуктивно. Отойдите, дайте поработать подсознанию.

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

В отладке есть место эмпатии

Вот то, о чем никто не говорит: отладка — это не только о коде. Это о понимании того, что на самом деле чувствуют пользователи.

Когда пользователь сообщает о проблеме, он не описывает ее техническими терминами. Он говорит: «тормозит» или «не работает». Ваша задача — перевести человеческий опыт на язык технического расследования. Что делал пользователь? Чего ожидал? Что произошло на самом деле?

Этот перевод требует эмпатии. Вам необходимо представить себя на месте пользователя, с его устройством, его интернетом и его уровнем терпения. Ошибка, которая никогда не воспроизводится на вашей машине для разработки, может воспроизводиться каждый раз на его телефоне в сельской местности с нестабильной связью. Если вы не способны проникнуться ситуацией такого пользователя, вам никогда не найти эту ошибку.

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

Исправленные сегодня ошибки предотвращают ошибки завтрашние 

Каждая решенная проблема пополняет вашу библиотеку паттернов. В следующий раз вы быстрее распознаете симптомы. Будете знать, куда смотреть. Избежите той же ошибки в новом коде.

Вот почему опытные разработчики допускают меньше ошибок. Дело не в том, что они более внимательны. Дело в том, что они уже совершили все ошибки. Они отладили столько проблем, что их интуиция натренирована тысячами провалов.

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

Что отладка раскрыла во мне самом

Та трехчасовая борьба с пропущенной зависимостью научила меня не только лучше понимать React. Она научила меня собственному рабочему процессу. Я метался — пробовал случайные изменения без их понимания. Я избегал системного подхода, потому что он казался мне более медленным. Хотя системный подход позволил бы найти ошибку за 15 минут, а не за три часа.

Отладка — поиск ошибок не только в коде. Это поиск ошибок в собственном мышлении. Она выявляет ваши убеждения, ваши слепые зоны и ваше нетерпение. В каждой проблеме, как в зеркале, отражается какой-то изъян вашей ментальной модели.

Разработчики, которые совершенствуются быстрее всех — не те, кто совершает меньше ошибок. Это те, кто больше всех учится на совершенных ошибках.

Навык, который никогда не устареет

Фреймворки приходят и уходят. Языки эволюционируют. Инструменты меняются. Но способность посмотреть на неработающую систему и понять, почему она не работает, не исчезнет никогда.

Через двадцать лет React будет упоминаться в сносках. Методы отладки, используемые сегодня, станут неактуальны. Но процесс  — наблюдать, изолировать, выдвигать гипотезы, проверять — будет все так же работать. Стремление выяснить причину неудачи все так же будет ценным качеством.

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

Читайте также:

Читайте нас в Telegram, VK и Дзен

Перевод статьи Mubashir: Why Debugging Is the Most Important Skill in Web Development

Предыдущая статьяКак выбрать ноутбук для разработки