Как привести проект в чувство27.10.2020 11:17

Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.

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

Предисловие

В этой статье я буду опираться во многом на (осторожно, субъективное мнение, подтвержденное только внутренним чувством и количеством репозиториев на github) самый популярный сборщик статики — webpack. Если по какой-то причине в вашем проекте используется другой сборщик, то ничего страшного: аналоги инструментов, про которые пойдет речь, с большой вероятностью найдутся в поиске.

Но мой совет: если ваш проект не является npm-модулем, переведите сборку статики на webpack, так будет проще.

Метрики

Первое, что нужно сделать, это собрать метрики. Они помогут понять, что ситуация стала лучше, а не хуже. Можно начать с веса статики (JS, CSS, HTML, картинки и т.д.). Делается это на удивление просто: собираем продовую версию проекта и получаем вес файлов. Второй важной для нас метрикой можно считать web-performance. Её можно получить с помощью Lighthouse. Проводим замеры, сохраняем оценки. И мы готовы начать.

Неиспользуемые файлы

Нам необходимо облегчить себе жизнь за счёт удаления неиспользуемых файлов. Они мешают воспринимать проект, и порой могут сильно путать. К примеру, один раз я удалил файлов на полпроекта, они просто нигде не использовались. Для решения этой задачи можно использовать плагин под webpack — unused-files-webpack-plugin. Подключаем плагин, запускаем сборку, получаем в консоль список мусорных файлов. У плагина есть параметр failOnUnused, значение по умолчанию — false. Если вы хотите сделать проверку строгой, то меняем значение на true, и сборка будет падать, если кто-то оставит в проекте лишний файл.

Статический анализ кода

Мы удалили лишние файлы, а значит не попадем в ситуацию, когда после исправлений в конкретном файле оказывается, что он не нужен, и мы впустую потратили время. Первое, что рекомендую установить на вашу IDE, это плагин SonarLint. Он умеет анализировать не только JavaScript, но и множество языков (полный список тут). Устанавливаем, проверяем весь проект, видим ошибки, правим — профит.

Это, конечно же, не всё. Теперь нужно установить и настроить ESLint. Обратимся за помощью к довольно популярному конфигу от Airbnb: если у вас не React — eslint-config-airbnb-base, а если React — eslint-config-airbnb. Они различаются набором правил. Например, в пакете для React будут прописаны правила от ESLint-плагинов: eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y. Некоторые правила являются вкусовщиной, и если вам не по душе, например, висящие запятые, всегда можно поменять настройку правила.

Третьим шагом в нашем крестовом походе за стиль кода и качество кодовой базы будет подключение eslint-plugin-sonarjs. Плагин для ESLint никак не заменяет плагин для IDE, а лишь приятно дополняет.

В первых трёх шагах мы делали упор на JS, но во фронтовых проектах немало стилей, давайте перейдем к ним. Для всего, что не является Stylus’ом, мы будем использовать Stylelint, а для Stylus — Stylint.

Ожидаемо, что после внедрения SonarLint, ESlint и Stylelint или Stylint будет куча ошибок. Необязательно всё править за один раз, можно временно отключить правила и исправлять их по порядку, или перенастроить их до фикса на warning.

Зависимости

Львиную долю кода в проекте составляют зависимости. Во-первых, было бы неплохо знать инструменты, которыми мы пользуемся. Во-вторых, эти самые инструменты могут плохо повлиять на web-performance вашего приложения.

Идеальным инструментом для решения этой проблемы является плагин под webpack bundle analyzer. Он позволит посмотреть, что у приложения под капотом, найти самые тяжелые зависимости, а также зависимости, которые не должны были попасть в продовую сборку (например, prop-types, redux-devtools, hot-loader и т.д.).

Но у зависимостей есть еще одна проблема: они любят дублироваться. В большинстве своем из-за неправильно собранных npm-пакетов и разницы между мажорными версиями npm-пакетов.

Инструмент, который поможет нам найти дубли: duplicate-package-checker-webpack-plugin (да, это очередной плагин под webpack). По аналогии с unused-files-webpack-plugin, его можно настроить на строгую проверку и завершать сборку при найденном дубле. Для этого нужно задать параметру emitError значение true.

Что мы будем делать с найденными дублями?

В любом случае, стоит освежить версии всех зависимостей.
Если это не помогло, можно поискать аналог пакета, который создает проблемы. Делать это можно через сервис bundlephobia.
Если аналога нет, попробуйте написать функциональность сами.
Если писать самому не вариант, сделайте pull request.

Журналирование

После очистки кодовой базы от неиспользуемых файлов, правки стиля и разбирательства с зависимостями стоит прикрутить журналирование ошибок. Для этого прекрасно подходит Sentry. Она (он или оно) являлась де-факто стандартом везде, где я работал. Установить Sentry можно двумя способами:

скриптом в HTML;
как модуль через npm.

Я рекомендую устанавливать скриптом в HTML. Почему? Представим, что пользователь заходит на сайт, на котором используется модный и современный JavaScript. У пользователя старый браузер, и если тот не поймет синтаксис, пользователь получит неработающее приложение. Ведь если Sentry был установлен через пакет, он не сможет инициализироваться, чтобы отловить эту ошибку.

CI-пайплайн

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

Для этого напишем немного скриптов в package.json:

"scripts": {
 "lint": "stylint src/ && eslint --ext .js,.jsx src/",
 "prod": "BABEL_ENV=production webpack --env=prod --progress",
 "build": "npm run lint && npm run prod"
}

Что мы получим:

Запускается линтинг JS (из package.json).
Запускается линтинг CSS (из package.json).
Запускается webpack (из package.json).
Запускается unused-webpack-plugin (из webpack).
Запускается duplicate-package-checker-webpack-plugin (из webpack).

Web-performance

Стоит потратить время на исправление ошибок, найденных Lighthouse (о нем я упоминал в начале статьи). В Chrome вы можете всё проверять вручную: переключитесь в режим разработчика, и попадёте во вкладку Lighthouse. Целесообразно проверять в режиме mobile: если в нём получится добиться хорошего результата, то в desktop всё будет отлично. Также можно использовать CLI.

Подведение итогов

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

Чего мы добились:

Очистили проект от мусора.
Стандартизировали стиль кода внутри проекта.
Уменьшили вес кодовой базы.
Улучшили UX.
Настроили мониторинг.
Собрали CI.

Как минимум, это всё можно использовать как аргумент на вашем performance review.

P.S.

Пример проекта с настройками можно посмотреть на github.