[Разработка веб-сайтов, JavaScript, Проектирование и рефакторинг, Системы сборки] Как привести проект в чувство
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.
Так звучит один из популярных вопросов на собеседовании для фронтенд-разработчиков. Я не знаю, что хочет услышать человек, задающий этот вопрос, но у меня есть ответ на его техническую составляющую и бэклог на несколько месяцев вперед.
Предисловие
В этой статье я буду опираться во многом на (осторожно, субъективное мнение, подтвержденное только внутренним чувством и количеством репозиториев на 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.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка веб-сайтов, Accessibility] Почему российские сайты не будут соответствовать ГОСТу по доступности
- [Разработка веб-сайтов, JavaScript, Angular, TypeScript] Давайте сделаем переиспользуемый компонент tree view в Angular
- [Проектирование и рефакторинг, Go] О репозиториях замолвите слово
- [Python, JavaScript, Java] Разбор вступительных задач Школы Программистов hh.ru
- [Разработка веб-сайтов, Python, Django] Что происходит, когда вы выполняете manage.py test? (перевод)
- [Программирование, Совершенный код, C++, Проектирование и рефакторинг] Наследование реализации в С++. Реальная история (перевод)
- [Анализ и проектирование систем, Совершенный код, Проектирование и рефакторинг, API] Чего ждать при работе с API: 5 (не)обычных проблем при интеграции приложений
- [Разработка веб-сайтов, Программирование, Dart, Flutter] Обновление роадмапа AngularDart (перевод)
- [Программирование, Проектирование и рефакторинг, Разработка игр] Как мы пришли к реактивному связыванию в Unity3D
- [JavaScript, Разработка игр, TypeScript, Логические игры] DagazServer: Как всё устроено
Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_javascript, #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_sistemy_sborki (Системы сборки), #_frontend, #_refactoring, #_webpack, #_eslint, #_sonar, #_lighthouse, #_sentry, #_blog_kompanii_domklik (
Блог компании ДомКлик
), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_javascript, #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_sistemy_sborki (
Системы сборки
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:09
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.
Так звучит один из популярных вопросов на собеседовании для фронтенд-разработчиков. Я не знаю, что хочет услышать человек, задающий этот вопрос, но у меня есть ответ на его техническую составляющую и бэклог на несколько месяцев вперед. Предисловие В этой статье я буду опираться во многом на (осторожно, субъективное мнение, подтвержденное только внутренним чувством и количеством репозиториев на 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. Что мы будем делать с найденными дублями?
Журналирование  После очистки кодовой базы от неиспользуемых файлов, правки стиля и разбирательства с зависимостями стоит прикрутить журналирование ошибок. Для этого прекрасно подходит Sentry. Она (он или оно) являлась де-факто стандартом везде, где я работал. Установить Sentry можно двумя способами:
Я рекомендую устанавливать скриптом в 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" } Что мы получим:
Web-performance Стоит потратить время на исправление ошибок, найденных Lighthouse (о нем я упоминал в начале статьи). В Chrome вы можете всё проверять вручную: переключитесь в режим разработчика, и попадёте во вкладку Lighthouse. Целесообразно проверять в режиме mobile: если в нём получится добиться хорошего результата, то в desktop всё будет отлично. Также можно использовать CLI. Подведение итогов  В самом начале я упомянул, что бэклога хватит на несколько месяцев вперед. Это не значит, что на всех проектах всё займет одинаковое количество времени. Это, скорее, в среднем по больнице, учитывая, что большую часть рабочего времени мы решаем проблемы бизнеса. Чего мы добились:
Как минимум, это всё можно использовать как аргумент на вашем performance review. P.S. Пример проекта с настройками можно посмотреть на github. =========== Источник: habr.com =========== Похожие новости:
Блог компании ДомКлик ), #_razrabotka_vebsajtov ( Разработка веб-сайтов ), #_javascript, #_proektirovanie_i_refaktoring ( Проектирование и рефакторинг ), #_sistemy_sborki ( Системы сборки ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:09
Часовой пояс: UTC + 5