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

  1. Метод грубой силы. Этот метод наиболее распространен и наименее эффективен. Здесь разработчик просто распечатывает все соответствующие стеки памяти и наблюдает за потенциальным местом несоответствия ожидаемым данным.
  2. Метод обратного отслеживания. Такой подход хорош в совсем небольших приложениях. Процесс начинается с того места, где обнаруживается конкретный симптом. Отсюда обратная трассировка выполняется по всему исходному коду. Шаги здесь: наблюдение за тем, кто был вызывающим для конкретной функции, доступ к ее вызывающей стороне, проверка, возникла ли там проблема, связанная с этой функцией. Если нет, переход к вызывающему этой функции и так далее.
  3. Метод устранения причины. Такой подход используется довольно редко. Это также называется индукция и дедукция. Данные, относящиеся к возникновению ошибки, организованы для выявления потенциальных причин. Разработчик создает гипотезу о причине ошибки и составляет специальную форму данных для передачи в функцию, которая должна подтвердить или опровергнуть эту гипотезу.
  4. Метод собственного опыта. Для этого необходимо хорошее знание продукта и его потенциальных слабых мест. В таком случае разработчик уже знает, что может быть причиной обнаруженной ошибки, основываясь на знании того, что API может быть неожиданно изменен, а исходный код чувствителен к такому изменению. Или тип данных был изменен, но в исходном коде нет соответствующей проверки на сбой.

Давайте рассмотрим некоторые практические методы процесса отладки.

Простой подход к отладке с выводом журнала

При таком подходе разработчик просто добавляет в код распечатки (console.log, alert и т. Д.). Это помогает понять некоторые промежуточные состояния, связанные с кодом. Этот подход находится где-то посередине между методами грубой силы и обратного отслеживания (однако, ближе к грубой силе). В системе, где в режиме разработки уже есть множество сообщений журнала, становится довольно болезненно добавлять дополнительные журналы и сопоставлять эти журналы с конкретным местом в коде. И, конечно же, всю эту информацию следует держать в голове у разработчиков, и есть большая вероятность сместить акцент с решения проблем на запоминание console.logs размещения и получение в конце своего мысленного переполнения стека. И в таком случае разработчик уже должен полагаться на инструменты сопоставления источников, чтобы не иметь дело с минифицированным кодом.

Отладка с REPL

REPL расшифровывается как Read Eval Print Loop. Такие инструменты представляют собой компьютерную среду, подобную оболочке, в которую можно ввести команду, а система отвечает выводом в интерактивном режиме. Если разработчик имеет доступ к модулю исходного кода, легко создать стратегию метода устранения причин. Например, разработчик уже определил потенциальное место ошибки кода и с помощью REPL может передать данные гипотезы, чтобы доказать, что это правильное местоположение ошибки.

Отладка с помощью инструментов разработчика

Инструменты разработчика - отличное место для получения подробной обратной связи от системы. Например, Chrome Developer Tools помогает отлаживать не только сам JS-код, но и сетевые вызовы, кучи памяти, замыкания, ставить точки останова на вызов интересующей функции, отлаживать DOM браузера и связанные с ним вычисления css.

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

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

С помощью раздела Scope можно легко наблюдать текущее лексическое окружение и анализировать, верны ли данные, переданные внутри, или нет. Это дает разработчику возможность применить стратегию метода устранения причин. Для этого вы можете сохранить некоторую часть области видимости как глобальную переменную и на ее основе производить некоторые манипуляции.

После этого эти данные будут доступны в разделе «Консоль» с соответствующим именем (обычно они называются temp1, temp2,…), и разработчик может проделать с ними некоторые манипуляции.

Для перехода от текущей точки останова в коде используется специальная панель навигации или соответствующие горячие клавиши.

Однако процесс отладки довольно сложен, если в системе нет одного места, где хранится состояние. Иногда требуется установить несколько точек останова, чтобы выявить несоответствия. Но даже в этом случае в Chrome Dev Tools есть специальный раздел с именем Breakpoints, в котором описаны все точки останова, которые вы уже добавили в исходный код.

Еще один интересный подход, который поможет вам получить отладку бесплатно, - это изменить код напрямую, не выходя из Chrome (функция, называемая рабочими областями).

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

Иногда это кажется излишним, потому что ваш редактор или даже IDE могут делать гораздо более крутые вещи. Но для какого-то царапинного примера кода вау-эффект гарантирован :)

Заключение

В соответствии с выбранным подходом к отладке на рынке доступно множество инструментов. Например, в каждой большой библиотеке есть некоторые передовые методы и инструменты для отладки, выпущенные сообществом.

WebStorm IDE предоставляет отличный набор инструментов для настройки отладки с различными предустановками. Но общая идея, внешний вид и ощущения почти такие же, как и в Chrome Dev Tools. В нашей компании мы активно используем его для отладки кодовой базы NodeJS.

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

Если вы нашли эту статью полезной, нажмите кнопку 👏 и оставьте комментарий ниже!