Как обеспечить качество кода интерфейсных проектов

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

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

1 Распространенные проблемы в коде внешнего интерфейса

1.1 Беспорядочный стиль письма, плохой опыт чтения

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

1.2 Некачественный код, постоянно баги

Какой код низкого качества или высокого качества? Хороший код может привлечь вас, как чтение романа, а плохой код заставит вас не хотеть продолжать с первого взгляда или даже читать в течение длительного времени, не зная, что сказать.

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

Вы можете не поверить, когда достанете его, но следующие примеры взяты из реальных проектов. Сможете ли вы определить как можно больше проблем?

Рисунок 1

фигура 2

изображение 3

Рисунок 4

Рисунок 5

Изображение 6

Рисунок 7

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

1.3 Функции не разделены, логика совмещена, сложно читать и понимать

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

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

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

Я часто вижу студентов в различных сообществах, задающих вопрос такого рода: выбирается новый проект, какие три фреймворка — Vue.js, React и Angular — подходят? На самом деле, члены команды разработчиков более опытны в них, и любой из них может быть использован; если у большинства членов команды мало опыта разработки интерфейса или персонал недостаточно стабилен, Vue.js является наиболее подходящим выбором. , Зачем? Потому что это проще и удобнее в использовании. Vue.js в определенной степени ограничивает метод и стиль кодирования с помощью различных хуков, таких как prop, data,computed, method и watch, так что код, написанный младшими разработчиками, не будет слишком уродливым, поэтому он более и более популярнее в сообществе.Одна из причин восхищения.

2 Методы обеспечения качества кодирования интерфейсных проектов

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

2.1 Разработка спецификаций кодирования проекта

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

Так как же должны быть сформулированы стандарты кодирования?

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

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

2.2 Настройка проверки и исправления стиля lint в рабочем процессе разработки

Внедрение инструментальной помощи в рабочий процесс разработки может обеспечить принудительную проверку lint в процессе написания и отправки кода. Что можно сделать? Все дороги ведут в Рим. Ниже приведен пример популярной схемы Git Hook для справки.

2.2.1 Редактор разработки и настройка инструмента lint

Настраиваем в проектеTSLintплагин для проверкиtypeScript; настроитьstyleLintПлагин для проверки CSS/LESS.

Мы согласны с тем, что команда разработки используетvscodeредактор и установите по крайней мере следующие плагины для помощи в разработке:

  • TSLint
  • stylelint
  • Document This
  • EditorConfig for VS Code
  • Prettier - Code formatter
  • Debugger for Chrome

2.2.2 Добавьте файл .editorconfig

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

Ссылка на конфигурацию:

# http://editorconfig.org
root = true

[*]
indent_style = space                    # 输入的 tab 都用空格代替
indent_size = 2                         # 一个 tab 用 2 个空格代替
# end_of_line = lf                      # 换行符使用 unix 的换行符 \n
charset = utf-8                         # 字符编码 utf-8
trim_trailing_whitespace = true         # 去掉每行末尾的空格
insert_final_newline = true             # 每个文件末尾都加一个空行

[*.md]
trim_trailing_whitespace = false        # .md 文件不去掉每行末尾的空格

2.2.3 Настройка Git Hook для принудительного обнаружения и исправления стиля кодирования

с помощьюGit Hook, вы можете выполнять обнаружение и исправление стиля при отправке кода.Если какой-либо контент не может быть передан, отправка будет заблокирована, чтобы реализовать обязательное внедрение стандартов кодирования.

Для достижения этого процесса можно использовать следующие инструменты:

  • huskyОн установит ряд git-хуков для проекта..git/hookкаталог, эти хуки могут обнаружитьpackage.jsonсерединаscriptsКонфигурация команды сценария и выполнение ее при отправке кода (здесь мы используемpre-commitкрюк)
  • lint-stagedВы можете получить все отправленные файлы и последовательно выполнить настроенные команды задачи.
  • styleLint/TSLint/ESlintРазличные инструменты проверки ворса могут быть настроены наlint-stagedв задаче
  • prettierнастроить наlint-stagedВ задаче можно изменить стиль кодирования, который может быть автоматически отформатирован

package.jsonСм. соответствующую информацию о конфигурации в:

{
  "scripts": {
    "precommit": "lint-staged",
  },
  "lint-staged": {
    "*.ts": [
      "tslint --fix",
      "prettier --parser typescript --single-quote --print-width 120 --write",
      "git add"
    ],
    "*.less": [
      "stylelint --fix",
      "prettier --parser less --print-width 120 --write",
      "git add"
    ]
  },
  "devDependencies": {
    "husky": "^0.14.3",
    "prettier": "^1.13.5",
    "prettier-stylelint": "^0.4.2",
    "stylelint-config-standard": "^18.2.0",
    "stylelint": "^9.4.0",
    "stylelint-config-prettier": "^4.0.0"
  }
}

.prettierrcСсылка на файл конфигурации:

{
  "singleQuote": true,
  "trailingComma": "es5",
  "printWidth": 120,
  "overrides": [
    {
      "files": ".prettierrc",
      "options": { "parser": "json" }
    }
  ]
}

.stylelintrcСсылка на конфигурацию конфигурации:

{
  "extends": [
    "stylelint-config-prettier",
    "stylelint-config-standard",
    "./node_modules/prettier-stylelint/config.js"
  ],
  "rules": {
    // 定义一些适合团队约定的规则
  }
}

С приведенной выше конфигурацией, когда код будет отправлен, он будетpre-commitсценическое исполнение.git/hook/precommitхук, который находит и выполняетscrpitsсерединаprecommitкоманда, такlint-stagedОпределенные задачи будут выполняться одна за другой. Эта схема также является относительно популярной практикой в ​​настоящее время и применяется во многих проектах с открытым исходным кодом.

Дальнейшее чтение:

2.3 Выполнение проверки кода

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

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

Какой код хороший, а какой плохой? Это происходит от накопления знаний, опыта применения и разработки. В конечном счете, некачественное кодирование связано с разным опытом и уровнями. Для отдельных лиц, чтобы накапливать самосовершенствование посредством непрерывного обучения, командам необходимо проводить обзоры кода.

Так как же должен работать Code Review?

Проверка кода может принимать разные формы. Например, многие популярные проекты на GitHub используют метод рабочего процесса PR (Pull Request), который можно включить только после как минимум трех проверок и утверждений, что может лучше гарантировать качество кода проекта из процесса. В некоторых командах разработчиков или на предприятиях внедряется gerrit, платформа для проверки кода, и процесс примерно аналогичен. Но для многих команд быстрой итерационной разработки бизнес-продуктов эта модель, требующая проверки и утверждения несколькими людьми, не подходит: рабочая сила ограничена, времени мало, и особо не о чем заботиться, так что даже геррит — простая формальность, а качество кодирования может лечь только на плечи отдельного разработчика.

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

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

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

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

Дальнейшее чтение:

2.4 Написание модульных тестов

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

Наши текущие основные требования к модульному тестированию проектов таковы:

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

Три основных фреймворка Vue.js/React/Angular имеют законченную систему реализации юнит-тестов, стоимость внедрения юнит-тестов в проект невелика, но высок процесс написания тестового кода. В некоторых случаях я думаю, что эта «высокая стоимость» того стоит. Кроме того, следует отметить, что выполнение модульных тестов должно быть интегрировано с CI, чтобы действительно играть роль обратной связи в реальном времени о проблемах.

2.5 Другое

2.5.1 Использование языка статической проверки TypeScript/Flow

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

Иногда я вижу, как некоторые студенты, изучающие back-end, говорят, что front-end не выглядит таким уж сложным, и я начал программировать всего после одного дня обучения. Они могут быть правы, но когда опытные студенты, изучающие интерфейс, смотрят на код, который они создают в это время, они часто говорят, что не могут смотреть прямо. Многие студенты, изучающие фронтенд-разработку, не специализируются на компьютерных специальностях и не имеют достаточного базового теоретического знания в качестве фона.Более распространено «делать все, что вы хотите» в выводе кода, когда вы впервые начинаете работать.

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

2.5.2 Создание платформы статистики отслеживания страниц

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

Дальнейшее чтение:

3 Связанные ссылки

Какой у вас опыт работы с качеством внешнего кодирования? Добро пожаловать для обсуждения и обмена вместе.

Категории