[Перевод] 10 принципов масштабируемых фронтенд-проектов

?v=1

С момента своего возникновения веб-приложения прошли долгий путь. Мы знаем, какую важную роль играет в вебе JavaScript и какие безграничные возможности есть у нас при выборе фреймворков и технологий. Каждый фреймворк имеет свои достоинства и недостатки, но почти во всех используются какие-то основные методологии. Такие инструменты как create-react-app, next.js, vue-cli и другие действительно полезны для начального формирования проекта и его структуры, но в остальном вы вольны создавать приложение в соответствии со своими предпочтениями и требованиями проекта.

В статье собран список принципов, которые будут полезны при создании веб-приложений с помощью React и Vue. Они помогут вам задать нужное направление и упорядочить разработку. Большинство этих принципов применимо к созданию любого ПО, но всё же список предназначен именно для веб-приложений.

1. Разрабатывайте компоненты, а не экраны


  • Старайтесь инкапсулировать всю логику компонента, чтобы его можно было легко отобразить где угодно, например, на разных экранах и в разных разделах.
  • Все CRUD-операции обращаются за необходимыми данными к контроллерам/поставщикам. Эти данные потом передаются компонентам, которые с ними связаны. Один из распространенных подходов заключается в использовании redux/vuex: данные сохраняются в хранилище и рассматриваются как истинные, а контейнеры извлекают нужную информацию.


2. Разделяйте уровни представления и бизнес-логику/управление


Не всем компонентам нужно подключение к хранилищам, серверному API или каким-то иным сервисам. Когда делаешь компоненты «безразличными к источнику данных», очень сильно повышаются возможности по их многократному использованию.

3. Применяйте стандартный способ извлечения данных


  • Этот принцип замечательно иллюстрирует rest-hooks, который поощряет создание простой и понятной структуры вызовов API.
  • Для некоторых проектов достаточно использования вызовов с явным извлечением данных. Но если вы работаете с многочисленными источниками и взаимосвязями, то вам поможет абстрагирование серверного API.


4. Используйте общую стратегию ввода информации пользователями


  • Сюда относятся формы, выбор меток, проверки и валидации, ошибочные состояния.
  • Есть подходящие решения уже из коробки: библиотеки с компонентами пользовательского интерфейса предлагает antd.
  • Если вы создаёте приложение без использования UI-библиотеки, то постарайтесь стандартизировать элементы ради улучшения пользовательского опыта.


5. Пишите автоматизированные тесты


  • Компоненты лучше тестировать с помощью интеграционных тестов, например, Cypress.
  • Необходимо тщательно проверять бизнес-логику с помощью модульных тестов.
  • e2e полезно для smoke-тестирования больших пользовательских сценариев. Это поможет выявить регрессии между клиентами и API.


6. Используйте Storybook для создания компонентов многократного использования


Storybook — прекрасный инструмент для взаимодействия с дизайнерами и обсуждения функциональности. Он служит «руководством по стилю» для вашего приложения.

7. Используйте линтеры и средства форматирования


  • Примеры линтеров: ESLint, stylelint.
  • Большинство инструментов для быстрого старта, например, create-react-app, заранее установят для вас линтеры. Но если вы работаете со старой кодовой базой, то линтеры могут быть бесполезны.
  • Они помогают в поиске багов, но также могут применяться для формирования стиля кода, который пишет команда. Это снижает когнитивную нагрузку при работе над фичами, которые вы получили от своих коллег.
  • Плагин sonarJS eslint поможет улучшить качество кода за счёт проверки его логической структуры.
  • prettier — это прекрасный инструмент форматирования. Достаточно настроить его один раз и забыть. Очень полезно при работе в команде.


8. Избегайте глобальных стилей


  • Переопределения и сбросы могут быть глобальными.
  • Создать изолированные стили можно с помощью CSS-модулей или CSS-in-JS.
  • Локальные стили часто улучшают ситуацию с многократным использованием компонентов.


9. Используйте структурированное версионирование


Модель ветвления:

  • Например, gitflow — «модель ветвления для Git, созданная Винсентом Дриссеном».
  • Для командной работы необходимо наличие структуры в вашем версионировании. Но это будет полезно и при самостоятельной работе.


Инструмент для линтинга коммит-сообщений — commitlint

  • Полезен при создании списка изменений и поиске багов в ходе работы над проектом.
  • Правила по написанию коммит-сообщений в Angular часто подходят и для других проектов. А commitlint поможет соблюдать эти правила, когда будете писать свои сообщения.


10. Поддерживайте changelog


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

Список можно продолжать бесконечно


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

© Habrahabr.ru