Перевод статьи «How to limit front-end bugs».
Баги не радуют пользователей и замедляют работу наших продуктов. При этом фронтенд у нас более изменчив, чем бэкенд, а потому в нем риск появления багов выше. Как же нам уменьшить количество потенциальных багов?
Линтинг
Линтинг это поиск проблемных шаблонов или кода, не соответствующего заданным правилам стиля. Этот процесс может запускаться автоматически нашим редактором по мере написания кода, а также быть частью процесса непрерывной интеграции. Таким образом, линтинг обеспечивает высокую читаемость кода в процессе его производства.
Инструменты линтинга есть во многих языках программирования, включая JavaScript. Фактически, в мире JavaScript есть несколько линтеров, но самый популярный на данный момент – ESLint.
ESLint содержит множество правил, применимых к современному JavaScript-коду. Мы можем по своему желанию включать и отключать эти правила в настройках. Также в JSON-файле .eslintrc можно прописать, чтобы линтер лишь выдавал предупреждения об ошибках, но не препятствовал сборке. Вместо того чтобы составлять свод правил самостоятельно, можно просто принять набор правил, рекомендуемый сообществом.
Вот вы можете выловить баг в следующем коде?
ESLint очень просто устанавливается с помощью npm. Кроме того, существуют многочисленные плагины для редакторов кода, которые могут подсвечивать проблемы, найденные линтером. Посмотрите, как ясно мы видим проблемы в коде с помощью редактора VS Code с расширением ESLint:
Верно, там было больше одной проблемы!
Если мы пишем наш фронтенд на TypeScript, то для применения стилевых правил мы можем воспользоваться другим отличным линтером – TSLint. Его свойства очень похожи на свойства ESLint: конфигурация правил, предсборочные наборы правил и прекрасное расширение для VS Code.
Линтинг довольно просто внедрить в любой проект по разработке фронтенда, а выгоды, которые принесет его применение, значительны. Так что стоит попробовать.
Автоматическое форматирование кода
Можно ли автоматизировать исправление некоторых проблем, найденных линтером? Например, может ли какой-нибудь инструмент автоматически добавлять пропущенные точки с запятой? Да! Здесь нам пригодится форматирование кода. Посмотрите на следующий пример:
Это не самый простой отрывок для чтения на ревью кода. Есть ли там баги?
Prettier это инструмент форматирования кода, с помощью которого мы можем автоматически форматировать наш код при проверке. Расширения редактора кода, такие как Prettier extension в VS Code, также позволяют автоматически форматировать код при сохранении.
Итак, просто сохранив файл с кодом в VS Code, мы можем превратить наш код в нечто более читаемое:
Форматирование кода очень легко внедрить в свой рабочий процесс. Оно прекрасно работает параллельно с линтером и облегчает нам поиск проблемных мест в коде.
Статическая проверка типов
Статические типы тоже позволяют нам отлавливать баги по мере ввода кода. Можете определить проблему в функции JavaScript ниже?
Баг там, где мы ссылаемся на объект response. Линтер его не выловит. И нам тоже сложно увидеть ошибку, если только мы не очень близко знакомы с конкретным вызываемым web API. Что, если бы мы могли определять тип объекта response? Тогда компилятор мог бы проверить, правильно ли мы сослались на этот объект. Именно это позволяет нам делать TypeScript!
Теперь, если мы добавим тип для объекта response, сможете заметить проблему?
Приведенный выше скриншот сделан при работе в VS Code, а этот редактор имеет очень хорошую поддержку TypeScript и подсвечивает баги как можно скорее, приводя очень информативные сообщения об ошибках.
TypeScript накладывает статическую систему типов поверх JavaScript. В настоящее время он пользуется большой популярностью. Фактически, vue 3.x пишется с использованием TypeScript.
Компилятор TypeScript очень настраиваемый, поэтому нет разницы, работаем мы со старым или с новым проектом: все равно мы можем добавить в него TypeScript и начать отлавливать баги на более ранних этапах.
Автоматизированное тестирование
Линтинг, форматирование кода и статическая проверка типов не требуют много усилий при добавлении их в наши проекты. Автоматизированные тесты, напротив, требуют много труда, но зато они могут вылавливать более замысловатые баги, так что дело того стоит.
Jest это прекрасный инструмент модульного тестирования, которым мы можем пользоваться как для наших компонентов фронтенда, так и для функций JavaScript. Он очень популярен при тестировании React-приложений. Если тесты не пройдены, этот инструмент дает нам информативные сообщения об ошибках.
При написании модульных тестов полезно знать, какие зоны кода не покрыты. При использовании Jest вам нужно лишь добавить опцию —coverage и вы получите отличный отчет о покрытии кода.
Эта информация поможет нам спланировать, какие модульные тесты нужно написать в будущем.
Модульные тесты дают нам уверенность, что отдельные кусочки нашего приложения работают и продолжают работать по мере разработки нашего приложения. Однако они не дают нам уверенности, что при этом наше приложение в целом будет оставаться рабочим. Здесь нам поможет сквозное тестирование.
Cypress это отличный инструмент сквозного тестирования, позволяющий нам создавать наши тесты на JavaScript. Cypress особенно блистателен при отладке, потому что тесты запускаются внутри браузера, а это значит, что к нашим услугам все инструменты разработчика Chrome.
Помимо того, что сквозные тесты дают нам уверенность в работе нашего приложения в целом, их еще и легко добавлять к существующей кодовой базе, ведь они не привязаны к коду.
Сквозные тесты также могут быстро покрывать зоны нашего приложения. Они менее прочные, поскольку зависят от всех слоев нашего приложения. Маленькое изменение в данных, лежащих в основе приложения, может послужить причиной лавины провалов тестов без определения настоящего бага.
Несмотря на высокую цену ошибок, хорошая комбинация надежных модульных тестов и сквозных тестов может помочь там, где не справляются линтинг и проверка типов.
Уменьшение количества кода путем использования фреймворков и библиотек
Еще один способ уменьшить количество багов в нашем коде это уменьшение размеров нашей кодовой базы за счет кода других людей. Преимущества, которые дают фреймворки вроде React, Vue или Angular, сэкономят вам тысячи строк кода и, что более важно, позволят не допустить целой кучи багов.
Все эти три фреймворка имеют активные экосистемы и отличные надежные библиотеки для таких вещей как управление состояниями и коллекции прекрасных UI-компонентов.
Но нужно проявлять осторожность, поскольку большое количество зависимостей может поставить перед нами проблему производительности, а с ней разобраться непросто.
Следите за производительностью
Чтобы приглядывать за производительностью при разработке приложений, мы можем пользоваться инструментами разработчика (DevTools) в Chrome.
Для начала, можно использовать вкладку «Сеть» (Network), чтобы посмотреть HTTP-запросы. Высока ли нагрузка? Возможно, какой-то ресурс вызывается слишком часто?
Большое количество веб-запросов или «болтливые» web APIs могут послужить причиной снижения производительности вашего приложения. Инструменты разработчика позволяют нам смоделировать запуск нашего приложения в условиях медленной сети, а это может особенно подчеркнуть проблемы такого рода.
В инструментах разработчика есть специальная вкладка «Производительность» (Performance). Мы можем записать период использования приложения, чтобы получить информацию с разбивкой по времени. Это поможет нам определить «узкие» места в производительности. Имеет смысл проверять область приложения, над которой вы работаете, чтобы убедиться, что производительность не снизилась.
Решение проблем с производительностью относится к разряду «дорогих», поскольку часто требует рефакторинга кода. Поэтому стоит использовать указанные выше инструменты регулярно, чтобы выявлять проблемы на ранних стадиях.
По возможности используйте чистые функции
Обратите внимание на этот код:
Функция принимает объект и возвращает тот же объект со значениями свойств строки, конвертированными в нижний регистр. Можете понять, в чем потенциальная проблема такого кода?
Ну, корень проблемы в том, что функция видоизменяет передаваемый ей аргумент. А от оригинального состояния передаваемого объекта может зависеть другая часть кода. Это мелкие, но дорогостоящие ошибки.
Версия того же кода, но с использованием чистой функции, будет выглядеть так:
Функция «чистая», поскольку всегда будет возвращать одинаковое значение для заданного аргумента и не будет производить никаких побочных эффектов вроде изменения аргумента. А это значит, что эта функция не приведет к багам в других частях кода.
Вторая версия нашей функции использует reduce – функцию для работы с массивами – для создания нового объекта без изменения оригинального. Есть и другие полезные функции для работы с массивами:
- concat – для добавления элементов в массив
- filter – для удаления элементов из массива
- map – для изменения элементов массива.
Регулярные проверки в разных браузерах
Поддержка всех основных браузеров является распространенным требованием. Если у нас такое требование есть и мы используем функционал, который раньше не использовали, можно проверить поддержку браузеров для этого функционала на caniuse.com. Нет ничего хуже, чем написать классный код, а потом обнаружить, что он не поддерживается в IE!
Наряду с этим можно делать выборочные проверки в разных браузерах по мере разработки нашего приложения. Такие инструменты как BrowserStack очень облегчают этот процесс.
Проактивно вылавливайте баги в продакшене
Мы можем делать все эти прекрасные вещи, описанные выше, однако баги все равно попадают в продакшен. И, согласитесь, было бы здорово, если бы мы могли их вылавливать и исправлять до того, как поступит жалоба от пользователей. Здесь нам пригодятся инструменты отчетов об ошибках (например, LogRocket). Их довольно много, есть, из чего выбирать.
Подобьем итоги
Итак. Мы разобрали много методов снижения количества багов в коде фронтенда. Некоторые из них дают моментальный эффект (линтинг и форматирование кода), другие требуют более значительных усилий (автоматизированное тестирование).
Ограничение количества багов и вылавливание их на ранних стадиях делает пользователей счастливее, а вам оставляет больше времени для создания нового классного функционала!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]