Инструменты и правила для разумной разработки Frontend без особых хлопот

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

Зачем читать это руководство?

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

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

Что в коробке?

- Редактор кода / плагины w
- Усовершенствование и линтинг
- Хуки Git
- Правила качества кода

Редактор кода

Даже в качестве отправной точки мы выбрали бы VSCode. Это редактор, а не полноценная IDE, как следует из названия, но со всеми плагинами и поддержкой сообщества он может быстро стать подобным IDE. Вот некоторые из преимуществ, которые предоставляет этот редактор по умолчанию:

- Легковесный (в начале)
- Настраиваемый
- В основном ориентирован на разработку JavaScript и друзей
- Расширяемый
- Встроенная интеграция с git, отладка, IntelliSense, интерфейс командной строки и многое другое.

Как вы также можете довольно быстро понять, он поддерживается Microsoft, поэтому нет неминуемой опасности стать неучастным проектом. Сообщество отличное, и усилия по разработке действительно сногсшибательны. Я предсказываю, что если этого еще не произошло, то он станет де-факто для большинства общих разработок (за исключением Java, которая, как мне кажется, еще не готова).

Расширения

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

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

  • Live Share: это расширение для меня - вещь номер один, которую вы должны интегрировать не только в редактор, но и в свою команду культуру. С его помощью вы можете поделиться интерфейсом редактора, файловой структурой, консолью и даже локальным сервером разработки. В моей компании мы широко используем спаривание, презентации и проверки кода.
  • Документируйте это: даже если мы хотим следовать нашим замечательным соглашениям об именах для классов, функций и аргументов, мы все можем ознакомиться с тем фактом, что действительно приятно проверять код, имеющий понятную и знакомую документацию. Это сэкономит вам много времени. Также прочтите эту статью , чтобы узнать, как можно интегрировать безопасность типов в обычный JS только с комментариями JSDoc в VSCode.
  • ESLint и Prettier: это тоже основные принципы наших правил украшения и линтинга. VSCode имеет первоклассную поддержку для обоих.
  • GitLens: лучшее расширение git, которое я нашел на данный момент.
  • Стоимость импорта: каждый раз, когда вы импортируете внешнюю зависимость в файлы проекта, это расширение будет показывать размер (в килобайтах), который вы добавляете в свое дерево зависимостей для приложения. Может показаться, что это приятно иметь, но при переходе на производственный уровень эти вещи имеют значение. Лично я, поработав с ними довольно долгое время, без них чувствую себя голым.
  • TODO Highlight: расширение, которое я лично считаю интересным, предоставляющее вам целенаправленные дополнения к вашим комментариям. Действительно здорово, что вы можете просто перечислить все свои TODO, FIXME и т. Д.

Расширения для технологий, с которыми мы застряли:
Давайте не будем забывать, что многие из нас будут работать в приложении, на котором есть некоторые отметки в истории. Например, у нас CoffeeScript, для вас это может быть Jinja или что-то в этом роде. Но мы не колебались и не лаяли на наших коллег, которые должны были принять решение, которое на тот момент казалось разумным. Итак, мы устанавливаем Coffee Lint.

Украшение и линтинг

Для линтинга мы выбрали ESLint в качестве линтера кода по умолчанию для наших проектов. ESLint - самый популярный, проверенный и расширяемый из доступных линтеров JavaScript. Я предлагаю вам определить (вместе с вашей командой) набор правил, которые могут быть общими для большинства проектов, которые вы будете выполнять, а затем просто пойти дальше и установить его как пакет npm, как мы сделали с нашим собственным.

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

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

{
 “trailingComma”: “es5”,
 “tabWidth”: 2,
 “semi”: true,
 “singleQuote”: false,
 “bracketSpacing”: true,
 “arrowParens”: “always”
}

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

Хуки Git

Поскольку мы интегрировали автоматический линтинг и украшение в наши проекты, было бы обидно, если бы мы случайно зафиксировали код, который не соответствует этим стандартам. Чтобы убедиться, что это так, мы настроили определенные хуки git, которые позволяют нам запускать настраиваемые процедуры перед каждой фиксацией, push или любым взаимодействием в жизненном цикле управления версиями. Чтобы настроить такую ​​автоматизацию наиболее простым способом, мы используем пакет Husky npm, который позволяет нам настраивать хуки git прямо из файла package.json.
На данный момент эти хуки обеспечивают предварительную фиксацию код отформатирован, но также не допускает никакого кода, который ESLint считает ошибочным. Это означает, что для фиксации кода в репозитории он должен соответствовать стандартам кодирования нашего проекта.

Качество кода

Так что это сложный вопрос, поскольку большинство будет утверждать, что любой набор правил может гарантировать Качество кода. Но я думаю, что мы можем исправить некоторые вещи, которые в конечном итоге избавят нас от многих головных болей. Из вещей, которые я нашел наиболее полезными, это правила, основанные на термине Сложность, который можно включить через ESLint. Я бы посоветовал вам подробнее изучить эту концепцию, и я обычно не предпочитаю ее, но статья в Википедии по этому поводу неплохая. Вот и набор правил, который мы используем:

{
 “complexity”: [2, 5],
 “max-statements”: [2, 7],
 “max-statements-per-line”: [ 2, { “max”: 1 } ],
 “max-nested-callbacks”: [2, 2],
 “max-depth”: [ 2, { “max”: 2 } ]
}

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

Все дело в эффективности

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