фон и зрение
В любом коллективе нормы - это тема, которую нельзя обойти У нас слишком много причин делать нормы, и у нас также слишком много болевых точек в выполнении норм Есть ли такой способ сделать нормы Эту вещь можно реализовать хорошо, и это не повлияет на эффективность наших исследований и разработок?
Что-нибудь, мы должны знать, где трудность в этом вопросе?
1. Для самой спецификации.
Нормативное понимание неоднородно. Каждый в команде по-своему понимает спецификацию, например, определение константы.Некоторым людям нравится использовать заглавные буквы, а некоторые считают, что нет необходимости беспокоиться об этой детали. Иногда все понимают границы спецификаций неодинаково.Некоторые люди думают, что наши спецификации являются нашими спецификациями уровня кодирования.Некоторые люди думают, что спецификации должны также включать вещи инженерного уровня, такие как структура каталогов файлов проекта.как.
вопрос затрат на оплату труда. Определяем спецификацию, нам необходимо соблюдать соответствующую спецификацию, стоимость работ может увеличиться, например, мы требуем точку с запятой в конце кода, иногда мы забываем добавить эту точку с запятой, мы требуем следить за верблюжьим регистром именования , но иногда не следовал. Поэтому нам нужно сделать код-ревью.
Сложность приземления. У каждого свои привычки кодирования, и единый стиль неизбежно приведет к разногласиям внутри команды. Цикл проекта будет плотным и свободным, что приведет к ощущению разделения между реальностью и идеалами, когда реальность будет реализована.
2. Для команды
У нас могут быть некоторые проблемы: стек технологий нашей команды не унифицирован, и многие публичные построения не могут быть осуществлены; в команде нет идеального документооборота, и все не могут сформировать единый нормативный консенсус; процесс стандартизации очень сложен. , цена очень высока, у нас может не быть соответствующих институциональных гарантий с точки зрения регулирования связанных систем.
Что касается спецификаций, наше видение облачных кредитов
Как показано на фиг.
Для спецификации наши точки облака делят спецификацию на три уровня, а именно определение спецификации, шаблон спецификации и инструмент спецификации.
1. Определение нормы
Содержание спецификации разнообразно, например, спецификация для GIT, спецификация для CSS, спецификация для JS и так далее.
Мы определяем эти спецификации и проходим через сторонние инструменты, автоматизированные проверки Lint, Commit Checks MSG и многое другое.
Каков принцип? Принцип заключается в том, что мы помещаем эти базовые спецификации в хук цикла, отправленный GIT, и сначала проходится проверка, а затем коммит может быть успешным. В то же время мы предоставляем соответствующие инструменты командной строки, напрямую ориентируемся на наш нестандартный код, напрямую форматируем обработку и делаем все возможное, чтобы снизить потребление энергии ручным трудом в этом процессе.
2. Стандартный шаблон
Вот как мы понимаем спецификацию в CloudPoints, которая является так называемой спецификацией, которая должна быть спецификацией определенного проекта, Нам нужно напрямую интегрировать все спецификации, которые мы определяем, в наш шаблон проекта.
Например, в репозиторий шаблонов Vue для этого репозитория мы интегрируем проверку GIT COMMIT, проверку ESlint, проверку Stylelint, предварительное определение структуры каталогов, выбор связанных публичных библиотек, библиотек компонентов и инструментов в нашей собственной библиотеке команды и так далее.
В каждой разработке мы ведем вторичную разработку прямо по такому шаблону.
3. Стандартизированные инструменты
В зависимости от ситуации в команде у нас могут быть разные репозитории шаблонов.В настоящее время нам нужно управлять этими интегрированными репозиториями шаблонов. Желаемое состояние, прямо через командную строку, генерируем нужный нам шаблон одним кликом. (вместо шаблона, который мне приходится каждый раз тянуть проект из определенного репозитория)
Этот инструмент спецификации может не только инициализировать шаблоны, но и напрямую добавлять страницы (страницы форм, страницы списков, страницы деталей), а также интегрировать некоторые плагины (например, для Stylelint, мы хотим добавить прямо из командной строки) в проект ).
Конечно, инструменты Node в нашей команде определенно не останавливаются на достигнутом.
Введение в спецификацию
Итак, что касается команды, какие аспекты нам нужны для стандартизации определения команды? Лично я считаю, что продвижение норм — дело долгосрочное, мы всегда будем сталкиваться с новыми сценариями и решать новые нормативные вопросы в новых сценариях.
нормативное содержание
Общая картина спецификации выглядит следующим образом:
Конечно, это только введение в содержание спецификации, на самом деле там все более сложные сопутствующие вещи.
Например: спецификация скрытых точек, спецификация мониторинга, общедоступная библиотека компонентов, общедоступная библиотека инструментов, общедоступный сброс css и т. д. Эти вещи должны быть построены внутри команды. На основе этих базовых возможностей мы можем проводить дальнейшую стандартизацию.
канонический шаблон
Шаблон спецификации означает, что мы определяем соответствующие спецификации и интегрируем их непосредственно в репозиторий шаблонов.
Дайте вам пример
Структура корневого каталога:
Структура каталогов в src:
Раздел автоматической проверки package.json:
Введение инструмента
По нашему мнению, наш инструмент должен состоять из трех частей:
1. Инициализация репозитория шаблонов.
2. Инициализируйте страницу шаблона.
3. Добавьте плагины, связанные с интеграцией в этот проект.
Так называемый плагин здесь предназначен для добавления одной функции в спецификацию проекта.
Принцип работы инструмента cli
Принцип этого требует, чтобы внешний интерфейс имел некоторое базовое представление об узле как об инструменте, и мы должны это знать.
Опубликуйте пакет npm: его ядром является атрибут mian в package.json, соответствующем файле js. возможность предоставления извне.
Опубликуйте инструмент cli: его ядром является атрибут bin в package.json, файле js, который необходимо выполнить.
1. Инициализируйте шаблон.
Принцип в том, что мы напрямую загружаем подготовленный шаблон прямо из командной строки.
Commander: пакет узла для взаимодействия с командной строкой.
download-git-repo: пакет узла для загрузки кода на git.
2. Добавьте страницу.
Принцип заключается в том, чтобы скопировать некоторые страницы, которые мы определили заранее, а затем поместить их в каталог нашего проекта. Или используйте ранее определенный шаблон для чтения файла и замены соответствующего содержимого.
3. Добавьте плагин
Суть в том, чтобы прочитать содержимое хранилища и добавить наши существующие возможности для текущего хранилища.
Например, если я читаю инициализированный шаблон без возможности eslint, то я могу напрямую добавить eslint в этот репозиторий шаблонов.Этот eslint является нормативным правилом, которое мы определяем, и его также можно выполнить в хуке цикла git.Проверьте код.
перспективы на будущее
Наша команда уже проделала немало работы, включая спецификацию, шаблон и уровень инструментов. Но вся нормативная система компании — это постепенный процесс. У нас еще есть довольно много контента для интеграции.
Характеристики:
1. Для нашего бизнеса с точками захоронения удобно для фронтенда добавить функцию захоронения точек одним кликом.
2. Для мониторинга нам необходимо единое фронтенд-мониторинговое решение, определенное в виде спецификации и интегрированное непосредственно в плагин.
3. Построение библиотеки инструментов, доступ к библиотеке инструментов и т. д.
Аспект шаблона:
1. Усовершенствована возможность существующего шаблона.
2. Расширение типов шаблонов (узел, апплет и т. д.)
3. Возможность обработки шаблона в формате JSON
Инструменты:
1. Возможность инструментов читать json и генерировать шаблоны.
2. Поддержка возможностей плагинов.
3, расширение плагина.