Отладка
Во всех современных браузерах есть мощные инструменты разработчика, которые позволяют быстро и удобно находить ошибки в коде. Главное, научится ими пользоваться. Далее для примера будет использован браузер Google Chrome как имеющий на данный момент наиболее мощный функционал для отладки.
Поиск ошибок в коде
Для поиска ошибок бизнес-логики в вашем коде вы можете воспользоваться точками останова (breakpoints), как из самого отладчика Chrome Dev Tools, так и написав в месте, на котором вы хотите остановиться ключевое слово debbuger. В точке останова вы можете увидеть текущее состояние вашей программы (для примера взят код главной страницы google.com):
Даже просто остановившись в какой-то точке, вы уже можете видеть очень многое, например, вы можете посмотреть значения всех переменных в коде, которые были проинициализированы/изменены до этого момента, вы можете увидеть call stack, текущий scope, event listeners и многое другое.
Если по ходу выполнения кода в точке останова вы увидели, что интересующая вас переменная содержит не то значение, которое вы ожидали там увидеть, то во вкладке Call Stack вы можете походить по вызовам, посмотреть, как менялся scope от вызова к вызову.
Так же вы можете следить за изменением значений определенных переменных или даже целых выражений (например, вызов функции с определенными переменными в качестве аргументов) добавив их в секцию watch:
По ходу выполнения кода, значения в наблюдаемых вами выражениях будут меняться, что позволит вам отловить тот момент, где что-то пошло не так.
Так же точки останова можно ставить не только на определенной строчке кода, но еще и на на:
- XHR вызовах;
- DOM-нодах;
- Event Listeners.
Например, если вы хотите отследить изменение в DOM-ноде, то просто найдите его во вкладке Elements или при помощи инструмента выделения элемента на странице, вызовите контекстное меню на найденом элементе и вы увидите пункт меню Break on...:
Здесь вы можете поставить необходимую вам точку останова, после останова на которой вы сможете посмотреть какой код привел к тому или иному изменению DOM-ноды.
Только лишь при помощи правильного использования точек останова можно разобраться с огромным спектром проблем, самое главное - пользоваться имеющимися у вас инструментами.
Поиск проблем производительности
В Chrome Dev Tools так же есть отличные инструменты для поиска проблем производительности. Проблемы могут быть вызваны разными причинами, но наиболее распространенные из них: частые reflow и неоптимальная работа с памятью.
Например, у нас есть приложение, которое сильно тормозит:
Мы видим, что frame rate приложения колеблется в районе 18 кадров в секунду, а должно работать с frame rate в 60 кадров в секунду. Чтобы понять, что происходит, мы можем перейти во вкладку Performance, записать profile рендеринга нашего приложения
Мы видим, что происходит очень частый reflow, а большую часть времени приложение тратит при выполнении функции app.update, плюс к этому мы можем прямо из вкладки Activity перейти на 62 сроку app.js и увидеть там затраты времени на выполнение конкретной строчки кода:
Мы видим здесь, что в данной строчке происходит получение значения offsetTop, что и вызывает reflow страницы. Исправив это, мы получаем заветные 60 кадров в секунду, а наша функция app.update теперь занимает около 10% от всего затраченного времени:
Чтобы было проще бороться с лишними reflow, вот список того, что может его вызвать.
Иногда бывает нужно более тонко попрофилировать часть кода, чтобы замерить производительность отдельных вызовов именно в какой-то его части. Для этого можно использовать console.profile и console.profileEnd. Между вызовами этих методов работа вашего кода будет профилировать, собранный профиль можно будет найти во вкладке Performance.
Поиск утечек памяти
В большинстве случаев, чтобы найти утечку памяти достаточно найти то, что занимает большую часть памяти. Сделать это можно при помощи сравнения двух Heap Spanshot. Перейдите во вкладку Memory, выберите опцию Take heap spanshot, после чего нажмите на кнопку Take spanshot
В данном снепшоте вы сможете увидеть текущий срез кучи js, а так же посмотреть что именно занимает наибольшее место в памяти:
Но это еще не говорит о том, что здесь есть утечка, так как утечку памяти мы можем определить только в динамике, то нам следует поработать с нашим приложением еще какое-то время, после чего сделать второй снепшот и сравнить второй снепшот с первым:
Теперь мы точно знаем, что утечка памяти есть, знаем что именно забивает наш heap, теперь можно найти место в коде, содержащее ошибку и пофиксить его.
Сложность может возникнуть, если утечек памяти много. В этом случае придется шаг за шагом отлеживать подозрительные места в динамике изменений и исправлять ошибки в коде. Если же утечка памяти есть, но она не столь очевидна, то можно попытаться локализовать проблему, после чего править код и делать снепшоты после внесенных исправлений. После нескольких итераций у вас будет достаточное кол-во снепшотов для сравнения эффективности ваших изменений.
Если же утечка памяти очень ярко выражена, то можно просто собрать Memory Allocation Profile, где можно увидеть место в коде, производящее наибольшее кол-во аллокаций:
Работа с сетью
Иногда требуется выявить проблему, связанную с выполнением сетевых запросов. Для этого можно воспользоваться вкладкой Network. Здесь можно установить необходимую вам скорость соединения, выбрав из существующих профилей или добавив свой собственный, посмотреть лог сетевых запросов, отфильтровать его для поиска проблемных запросов и так далее.
Лог запросов тоже можно кастомизировать. Кроме того, что включено по дефолту, есть много информации, которая изначально скрыта, но может помочь при поиске проблемы:
Так же график Waterfall может показывать не только время страта запроса, но и другие вещи, включая Total Duration, что может быть очень полезным при выявлении сетевых проблем:
Но иногда бывает нужно выдать свой браузер за другой. Для этого можно перейти в More Tools > Nework Conditions, где можно так же выставлять скорость соединения, отключать/включать кэширование запросов, но еще и указывать User Agent для выполнения запросов. Можно выбрать User Agent из списка, а можно добавить свой собственный:
Это может быть очень полезно, если вы хотите воспроизвести ошибку, найденную в редком браузере.
Так же бывают случаи, когда нужно посмотреть, что будет с приложением, если определенный сетевой запрос не выполнится вообще. Это можно сделать в More Tools > Request blocking.
После добавления паттерна блокировки можно увидеть сколько запросов было заблокировано.
Общий поиск проблем
На данный момент в Chrome Dev Tools есть отличный инструмент, позволяющий собрать список наиболее выраженных потенциальных проблем. Для этого перейдите во вкладку Adutids и нажмите Perform and audit, в результате вы получите крайне подробный отчет о потенциальных проблемах на вашем сайте. Он очень схож с Google Page Speed, но его можно использовать локально
Итог
Здесь перечислены наиболее распространенные сценарии использование Chrome Dev Tools, но это далеко не полный список того, что можно сделать с помощью этого инструмента. Если вы решаете какую-то задачу, то обязательно попробуйте найти подходящее средство для ее решения в Chrome Dev Tools, не мучайтесь с console.log, решайте задачи теми средствами, которые предназначены для их решения.