Определите правила, чтобы быть более эффективными

Вам знакомо это чувство, когда вы на 100% уверены, что в этот раз все будет по-другому? Вы представляете себе идеальный проект, в котором папки будут идеально структурированы, а каждая строчка кода продумана и расположена в нужном месте. Не будет бардака!

Но тогда счет файлов стремительно стремится к бесконечности; дедлайны настойчиво приближаются, а у вас нет времени даже на простые улучшения и в итоге вы теряетесь в своем коде.

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

Моя история

Когда я начал изучать React в 2018 году, я хотел найти лучший способ структурировать свой проект и организовать свой код. В тот момент я не знал правильного ответа для себя. Поэтому я решил осмотреться.

Библиотека Microsoft FluentUI была для меня самым значительным источником вдохновения. Я использовал его на работе и провел много времени с его компонентами. Кроме того, я получил массу полезной информации в их примечаниях к выпуску.

Определение моих правил

Когда я думаю об определении правил улучшения работы, я стараюсь вспомнить все, что меня огорчает. Да, грустно — правильное слово.

Например, у меня могут быть компоненты, которые кричат ​​о рефакторинге, или структура папок, где невозможно что-то найти, или плохо названные функции и переменные, которые усложняют мне жизнь.

Я все обдумал и определил моменты, которые хочу изменить.

Я хотел:

  1. Ускорьте процесс создания новых компонентов.
  2. Сделайте процесс выбора места размещения новой логики более доступным и понятным для всех членов команды.
  3. Сделайте процесс исправления ошибок и форматирования более доступным и автоматизированным.
  4. Найдите инструменты/методы, которые помогут сохранить один стандартный стиль в проекте.

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

Давайте углубимся в это.

Автоматически проверять и форматировать код

Работая над новым проектом, я всегда начинаю с конфигурационного линтера и форматтера. Самая популярная комбинация на сегодняшний день — ESLint + Prettier, которая работает хорошо; Мне нравится их использовать, но их настройка в новых проектах занимает некоторое время.

Конечно, вы сделаете это только один раз, так что это не так уж и плохо, но каждый раз, когда я добавляю эти два инструмента в проект, я немного напрягаюсь, потому что важно правильно определить файлы конфигурации и заставить Eslint и красивее понять друг друга, и это требует времени. Впрочем, есть много примеров использования Eslint с Prettier, поэтому я не буду вдаваться в подробности.

В своих новых проектах я экспериментирую с Rome, линтером и форматтером, поэтому мне нужно только установить его и определить свои правила в одном файле конфигурации. Установить Рим в проекте намного проще. Я еще не решил, заменю ли я ESLint + Prettier на Rome в будущем полностью, мне нужно много времени, чтобы поиграть с ним, но на данный момент он мне нравится. В моем проекте форматирование выполняется при сохранении автоматически, поэтому мне не нужно об этом думать.

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

Преимущества :

  1. Я определил, как должен быть отформатирован мой код, и вся команда использует эти правила.
  2. Линтер покажет все места, где программист делает что-то не так, или предложит лучший вариант; правила могут быть изменены в файлах конфигурации для достижения наилучших результатов.
  3. Более чистый и одинаково отформатированный код повышает удобочитаемость и эффективность команды.
  4. Процесс форматирования может выполняться автоматически при сохранении, поэтому даже новые члены команды сразу получат наилучшие результаты, не зная правил.

Определите структуру папок компонента

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

Структура файлов, которую я предпочитаю:

  • ComponentName.tsx, где определяется компонент.
  • ComponentName.module.scss, где определены все эти стили компонентов.
  • ComponentName.types.ts, где я поместил интерфейс для объекта реквизита компонента, все необходимые типы и перечисления.
  • ComponentName.test.tsx, где живут модульные тесты.
  • ComponentName.stories.tsx для Storybook в библиотеках, я не добавляю сборник рассказов в каждый проект.
  • useComponentName.ts — в кастомном хуке извлекается некоторая логика, предназначенная только для этого компонента, но для удобства чтения. Я предпочитаю использовать хуки для повторного использования логики, но иногда имеет смысл отделить часть логики от компонента, чтобы получить лучшие результаты.
  • index.ts — файл компонента экспорта файлов и его типы

Я не всегда кладу свои компоненты в отдельные папки; если компонент слишком мал или используется только в одном файле, его можно определить в том же или отдельном файле в той же папке. Мы не должны слишком усложнять вещи.

Определите идеальную структуру проекта

Звучит слишком абстрактно.

Не существует идеальной структуры для всех. Каждый проект уникален своей сложностью, выбранными библиотеками и предпочтениями команды. То, что работает для одного, может не работать для кого-то другого. Команда React не ограничивает вас; вы можете выбрать лучший подход, который работает для вас.

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

  1. Эволюция структуры папок React и зачем сразу группировать по фичам
  2. Структура папки React за 5 шагов [2022]

Будем честны; мое видение идеальной структуры проекта пришло ко мне не за один день. Но это был увлекательный эксперимент.

В 2019 году я пытался убедить свою команду, что мы должны разделить компоненты на контейнеры (с сохранением состояния) и компоненты (без сохранения состояния), потому что тогда это был самый популярный способ. Но, к сожалению, у нас это не сработало; создавать новые компоненты стало намного дольше и неудобнее.

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

Принципы, которым я следую:

  1. Каждый компонент имеет свою папку.
  2. Вся логика, принадлежащая одному компоненту, должна находиться в папке этого компонента (например, в хуке есть Reason, но его использует только один компонент).
  3. Вся общая логика должна находиться в стандартных папках — хелперы, константы, хуки, редукторы…
  4. Общие компоненты пользовательского интерфейса, такие как кнопки, средства выбора и списки, остаются в папке компонентов.
  5. Структурируйте папки по фичам — каждую фичу рассматриваю бизнес-процессом.

Используйте расширения VSCode для определения правил

Работая с VSCode, вы будете использовать различные расширения, которые помогут вам упростить программирование и повысить продуктивность. Я хочу рассказать вам о расширениях, которые я предпочитаю использовать, чтобы мои проекты были чистыми и организованными.

Большую часть времени я не одинок в проекте, и мне нравится, когда программисты придерживаются одного стиля и пытаются найти способы помочь им достичь этого.

Давайте посмотрим на мои любимые расширения для установки правил в проекте.

Шаблоны папок

Я люблю это. Вы можете использовать его не только для React и определить любой шаблон, какой захотите. Я использую его для создания компонентов. У меня есть предопределенная структура папок компонентов со всеми файлами, которые могут быть с правильными именами и примитивным кодом в файлах.

Преимущества:

  1. Программист может создать новый компонент за 5 секунд.
  2. Структура компонента будет создана в соответствии с правилами, заданными в проекте.
  3. У вас может быть несколько шаблонов для разных вариантов использования.
  4. Файлы в папке компонента будут иметь код по умолчанию, так что вы сразу же получите работающий компонент со всеми правильными импортами, стилями и даже примитивными модульными тестами. Программисту не нужно думать о типах экспорта — именованных или по умолчанию или о том, как правильно стилизовать компоненты; все будет определено в шаблоне.
  5. Программисту не нужно копировать существующие компоненты и переименовывать файлы, удаляя бесполезный код. Я стараюсь максимально избегать копирования в проекте, потому что если вам нужна какая-то текущая логика, вы должны найти способы ее повторного использования, а не копирование-вставку. Кроме того, создание новых компонентов путем копирования существующих обычно приводит к беспорядку, потому что программисты забывают переименовывать переменные и функции и оставляют бесполезный код. Конечно, пулл-реквесты помогут отловить эти проблемы, но гораздо лучше предотвратить эту проблему, чем потом ее решать.

Рефакторинг VSCode React

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

В этом поможет VSCode Refactor — выберите код, который хотите отделить, и нажмите на светящееся облачко. Вы получите новые компоненты очень быстро.

Проверка орфографии кода

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

Делайте заметки и делитесь своими знаниями

Есть много потрясающих статей об эффективном программировании, отличных инструментах и ​​лучших практиках, но это не поможет, если вы забудете о них сразу после прочтения. Мы много читаем и получаем массу полезной информации. На мой взгляд, важно делать заметки (на бумаге по электрике), добавлять фантастические статьи в закладки и делиться своими знаниями с коллегами.

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

Не забывайте об обмене знаниями; даже великие правила никогда не помогут вам добиться наилучших результатов, если никто им не следует.

Это все о моих правилах для проекта React. Я надеюсь, что эти советы будут полезны.