Как управлять интерфейсным кодом вашей команды?

внешний интерфейс спецификация кода

предисловие

Код — это актив компании. Особенно важно, как управлять этим активом. Самостоятельно построенный gitlab является очень простым и необходимым. Настоятельно рекомендуется использовать Gitlab для управления версиями.Самостоятельно созданный Gitlab несложный и простой в управлении, включая управление кодом, управление разрешениями, запрос журнала отправки и привязку к некоторым сторонним плагинам.

Некоторые компании могут по-прежнему использовать svn или какой-либо инструмент управления версиями (RTC), который предоставляет IBM. Но все же не так хорошо, как гитлаб с ними гладко. Настоятельно рекомендуется для управления кодом Gitlab.

Разработка спецификаций разработки кода Code Guide

Зачем нужна спецификация командного кода?

Хотя эти детали тривиальны, никакого опыта или оптимизации производительности не будет, но они отражают профессионализм кодера и команды.Видение команды: стать отличной веб-командой в отрасли! Так что сколько бы человек ни было в команде, кодовому стилю должна обучать одна семья!

Взяв в качестве примера веб-интерфейс, давайте посмотрим, какие аспекты спецификации кода, вероятно, будут включать:

соглашение об именовании
  • Нейминг проекта
  • Имя каталога/папки
  • Именование файла JavaScript
  • css (scss, меньше) имя файла
  • имя файла html
Спецификация кода файла HTML
  • атрибут ЯЗЫК
  • кодировка строки
  • режим совместимости с IE
  • CSS способ введения
спецификация кода файла css
  • отступ
  • точка с запятой
  • пространство
  • Сворачивать
  • Схема аннотации
  • имя
  • запросы средств массовой информации
  • и т.п. . .
Файл спецификации кода JavaScript
  • 缩进、空格、换行、注释。 . .
  • именование переменных
  • ссылка на функцию
  • объект массива
  • ......разное

В соответствии с соответствующей схемой может быть сформулирована вышеупомянутая спецификация разработки. Здесь мы настоятельно рекомендуем спецификации разработки javascript команды Tencent AlloyTeam и команды airbnb.

Code Guide by @AlloyTeam

Airbnb JavaScript Style Guide

Проверка кода ESlint

  • Уменьшить вероятность ошибки низкоуровневой ошибки (таких как задачи орфографии) возникают;
  • повысить ремонтопригодность и читабельность кода;
  • Жесткий единый стиль кода упрощает совместную работу команд;

ESlint рекомендует настраивать его непосредственно в скаффолдинге, что значительно поможет нам улучшить ремонтопригодность нашего кода.

Ссылка на китайскую сеть ESLINT

Улучшение кода

Prettier, как следует из названия, — это сравнительный уровень красивого, что можно перевести как «красивее». Так что же такое Prettier? отБолее красивая домашняя страница официального сайтаМожно посмотреть, что это:

  • Самоуверенный форматировщик кода (самоуверенный форматировщик кода)
  • Поддерживает множество языков
  • Интегрируется с большинством редакторов
  • Имеет мало параметров (слишком много параметров конфигурации для других инструментов форматирования кода)

Prettier чрезвычайно прост в установке и использовании:

// with yarn
yarn add prettier --dev --exact
# or globally
yarn global add prettier

// with npm 
npm install --save-dev --save-exact prettier
# or globally
npm install --global prettier

Он также прост в использовании

prettier [opts] [filename ...]

prettier --check "src/**/*.js"

В частности, вы можете увидетьБолее красивая домашняя страница официального сайтаВведение.

Хаски из Pre-commit Hook Tool

Husky может предотвратить неправильный коммит git, git push и многое другое 🐶 гав!

Это объяснение всего инструмента для Хаски. Другими словами, вставьте операцию ловушки перед отправкой кода, выполните эту операцию до того, как вы сможете отправить код, чтобы избежать отправки плохого кода. Поскольку во многих случаях спецификация заключается в том, что не обязательно каждый член команды будет выполняться каждый раз, поэтому перед отправкой кода вставляется операция (NPM Run XXX), что также является защитой целевого слоя, обращенного к коду.

В настоящее время основным подходом является использование Prettier на предыдущем шаге. Предположим, вы установили NPM/YARN, тогда посмотрите, как использовать

// package.json
{
  "lint-staged": {
    "**/*.{js,ts,tsx,json,jsx,less}": [
      "node ./scripts/lint-prettier.js",
      "git add"
    ],
    "**/*.{js,jsx}": "npm run lint-staged:js",
    "**/*.less": "stylelint --syntax less"
  },
  "husky": {
    "hooks": {
      "pre-commit": "npm run lint-staged",
      "...": "..."
    }
  }
}

npm run lint-staged,а такжеlint-staged

  • node ./scripts/lint-prettier.js
  • git add

Очевидно, что lint-prettier.js в основном читает более красивый файл конфигурации и проверяет, были ли улучшены соответствующие файлы правил. Если нет, он выдаст соответствующие подсказки:

// lint-prettier.js 部分代码

      const isPrettier = prettier.check(input, withParserOptions);
      if (!isPrettier) {
        console.log(files);
        console.log(
          `\x1b[31m ${file} is no prettier, please use npm run prettier and git add !\x1b[0m`
        );
        didWarn = true;
      }

Поэтому Prettier + Husky также настоятельно рекомендуется для использования в проектах.

Typecript

Это также распространенная тема.Как надмножество JavaScript, typescript имеет следующие преимущества:

TypeScript повышает удобочитаемость и ремонтопригодность кода
  • Система типов на самом деле является лучшей документацией, большинство функций можно использовать, просто взглянув на определения типов.
  • Лучше отлавливать большинство ошибок во время компиляции, чем во время выполнения.
  • Улучшенный редактор и функциональность IDE, включая завершение кода, интерфейсы, подсказки, рефакторинг, рефакторинг прыжков к определению, рефакторингу и многое другое

В качестве простого примера, если соблюдаются наши спецификации кода, проверка eslint проходит, а также выполняется более красивая. Все, что можно сделать невооруженным глазом. При расчете 1 + 1 все еще существует проблема. Потому что вы просто не знаете или не уверены, является ли 1 строкой или числом, когда программа запускается. Если оба имеют числовой тип, то 1 + 1 = 2. Если это строка, то 1+1 = '11'.

Если позволяют условия проекта, используйте машинопись как можно скорее. Разумеется, при установке typescript обратите внимание на установку соответствующего плагина проверки:

// package.json 

"tslint": "^5.10.0",
"tslint-config-prettier": "^1.10.0",
"tslint-react": "^3.6.0", // 如果你是react项目

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

Другими словами, написание модульных тестов пользовательского интерфейса — одно из проявлений качественного кода. Когда мы разрабатываем компоненты, мы все знаем, что нужно следовать концепции высокой связности и низкой связанности. Как вы объективно оцениваете эту идею? Еще нужно пройти юнит-тесты.

Взяв за пример реакцию, Jest + Enzyme рекомендуется писать модульные тесты.

jest

Jest — это набор фреймворков для тестирования JavaScript с открытым исходным кодом от Facebook, который автоматически интегрирует все инструменты тестирования, необходимые разработчикам, такие как утверждение, JSDom, отчет о покрытии и т. д. Это фреймворк для тестирования с практически нулевой конфигурацией. И это очень удобно для тестирования React, который также является интерфейсной средой Facebook с открытым исходным кодом.

Enzyme

Фермент из Airbnb - это инструмент для тестирования JavaScript для реагирования, который позволяет вам судить, манипулировать и выводить выходные компоненты React React. API Enzyme делает манипулированием DOM и обхода гибким и интуитивно понятным путем побуждения API jQuery. Фермент совместим со всеми основными тестовыми бегунами и библиотеками суждения.

Точно так же код, который может писать модульные тесты, будет легче поддерживать и рефакторить позже.

проверка кода проверка кода

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

Обычно рекомендуется проводить обзоры кода (совместное использование) организованным образом с интервалом в одну итерацию или один цикл версии.

Эпилог

В этой статье в основном суммируются несколько моментов, на которые необходимо обратить внимание при управлении интерфейсным кодом:

  • Построить склад кода
  • Разработка базовых спецификаций написания кода
  • ESlint
  • prettier + husky
  • typecript + tslint
  • Модульное тестирование пользовательского интерфейса
  • проверка кода проверка кода

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

В то же время объедините Eslint, красивее, Tymdercript и т. Д. В конкретные проекты для выбора нескольких решений, которые подходят для вашей команды. Конечно, лучше всего выбирать все. Конкретная ситуация конкретный анализ. Хороший код - хороший актив, приятный глаз и легко поддерживать. Разработка передней стороны меняется с каждым днем ​​прохождения, а Eslint и Tslint имеют тенденцию сливаться. Нам нужно все время следить за этим. Вы должны узнать, если вы не можете учиться.

Категории