«Я только что изменил условие if и не ожидал, что это приведет к сбою непрерывной интеграции, сбою развертывания в результате и повлияет на тестирование QA других функций».
Повышение качества веб-приложений — очень интересная тема. Мы знаем, что есть ряд средств для улучшения качества кода, но по разным причинам мы этого делать не будем. В первом проекте, над которым я работал, поскольку все были молодыми (Junior Consultant), мы реализовали ряд базовых мер по улучшению качества приложения, таких как написание тестов, погоня за тестовым покрытием, запуск pre-commit скриптов и т. д.
В этом недавнем проекте мы столкнулись с похожей проблемой — необходимостью улучшить качество кода проекта. Итак, я хотел написать статью, чтобы представить соответствующий контент. Эту статью можно условно разделить на следующие части:
- Проблемы с качеством веб-приложений
- Используйте тестирование для улучшения качества
- Инструментирование кода с помощью Lint и Git Hooks
- Как предотвратить опасные отправки
Итак, вернемся к клише «качество веб-приложений».
Проблемы с качеством веб-приложений
Веб-приложения обычно сталкиваются с игрой между запуском и качеством — пока это не влияет на пользовательский опыт, небольшие ошибки часто «терпимы» для проекта. Таким образом, его можно запустить раньше и реализовать ценность для пользователя. Кроме того, есть последствия для развития: один — это цикл разработки гибких методов, а другой — возможность многократного запуска.
Таким образом, веб-разработка отличается от разработки программного обеспечения в некоторых специальных областях и отраслях.В этих особых отраслях рентабельное программное обеспечение может запускаться, развертываться только один раз, без второй возможности, например, система управления атомной бомбой. Есть также несколько типов случаев, которые являются автоматической системой вождения на смарт-автомобилях.Это много автомобилей, которые заняты автомобилем. Это эквивалентно веб-приложениям, которые можно обновлять удаленно. Но в этих системах больше гонятся за качеством системы, а не за скоростью разработки. Сбой развертывания веб-приложения может откатиться назад, хотя определенную сумму денежных потерь приносит редко, но очень мало приносит в жизнь.
Таким образом, вкачественныйа такжескоростьС одной стороны, в веб-разработке существует тонкий баланс.
Но разработка программного обеспечения — это не только вопрос качества и скорости, но и проблема продукта, то есть возможности сделать продукт, отвечающий потребностям пользователей. Таким образом, становитсякачество-скорость-спрос, более сложный баланс. Чтобы предоставить продукт, который больше соответствует потребностям пользователей, необходимо часто вносить изменения в некоторые требования. И в зависимости от времени внесения этих изменений это, как правило, влияет на качество кода и скорость разработки — чем короче время реализации требования, тем короче время его тестирования и тем выше вероятность ошибок. Я сталкивался с этим в прошлом, выходя в интернет сегодня вечером и временно меняя спрос во второй половине дня. Как вы понимаете, у тестировщиков нет времени на тестирование.
На данный момент непрерывная интеграция может только явно сказать нам, что наши тесты не работают, некоторые из наших функций не работают, и нам не следует развертывать эту новую версию. Однако дело не в том, что есть проблема с непрерывной интеграцией, мы не можем развернуть, мы все еще можем развернуть.
Блабла, так вот вопрос, какой самый действенный способ?
Используйте тестирование для улучшения качества
Чтобы гарантировать качество этого проекта, после отправки кода он пройдет серию тестов:
- модульный тест
- Автоматизируйте тестирование пользовательского интерфейса
- Разработчики проводят интеграционное тестирование вручную
- Тестировщики проводят 3-4 раунда тестирования
Если смотреть на тестирование проекта только с макро-ракурса, то в agile-проекте тестирование можно разделить на следующие этапы:
- Кабинетная проверка в среде Dev (разработка) в основном используется для демонстрации того, соответствует ли функция требованиям.
- Тестирование в среде QA (тестирование) для некоторых рутинных тестов.
- Тест среды ST (System Test), часто используемый для совместной отладки со сторонними системами. Эта среда необходима для интеграции при появлении сторонних систем.
- Тест среды UAT (User Acceptance Test, User Acceptance Test) обычно использует код бизнес-стороны, чтобы проверить, соответствует ли продукт требованиям.
Если веб-приложение может пройти такую серию тестов, его качество в определенной степени гарантировано. Таким образом, разработчики могут «безответственно» передавать функции непосредственно тестировщикам, если они не хотят жить слишком долго. смеяться~
Однако в некоторых компаниях количество ошибок может влиять на производительность, или ошибок так много, что они выглядят непрофессионально и т. д. блабла.
В общем, разработчикам было бы удобнее писать собственные тесты. Согласно теории тестовой пирамиды, нам нужны три типа тестов:
- Модульные тесты используются, чтобы убедиться, что наши базовые функции работают правильно и корректно.
- Сервисное тестирование, причем не только собственных сервисов, но и сторонних зависимых сервисов.
- UI-тесты, тесты, имитирующие действия пользователя.
Для внешнего проекта нам обычно нужны только два:单元测试а такжеE2E 测试. На самом деле, теоретически должно бытьUI 组件的测试, но вообще говоря, когда мы выбираем компоненты пользовательского интерфейса, мы будем учитывать стабильность компонентов.
Но в большинстве отечественных компаний написание тестов зачастую невозможно. Отступая назад, нам нужен более простой и дружественный способ сделать это.
Инструментирование кода с помощью Lint и Git Hooks
Перед отправкой кода мы также можем выполнить некоторые общие операции:
- Статический анализ кода (lint), используемый для статического анализа кода, например Lint4j, TSLint, ESLint.
- Чтобы запустить тесты, чтобы не повлиять на непрерывную интеграцию, нам нужно протестировать код перед фиксацией.
Современные редакторы (с соответствующими плагинами), IDE могут улучшать хорошие технические средства, статический анализ кода в процессе разработки, а также улучшать предложения в любое время. Например, Intellij IDEA и WebStorm напомнят разработчикам о некоторых проблемах спецификации кода TypeScript на основе TSLint.
Эти инструменты анализа в основном выполняют некоторый анализ кода.Как упоминалось в книге «Разработка приложений полного стека: бережливая практика», обычно выполняются следующие серии проверок стиля:
- Канонические имена функций и переменные
- Спецификация формата кода
- Ограничьте возможности языка
- предел функциональной строки
- Множественные ограничения вложенности
- неиспользованный код
- так далее
И эти нормы, если их не соблюдать, — игра. Итак, мы обычно полагаемся на Git Hooks, чтобы делать подобные вещи. Для проекта, который использует Git для управления исходным кодом, Git Hooks может делать такие вещи, которые можно найти в.git/hooksПосмотреть в каталоге:
applypatch-msg post-merge pre-auto-gc prepare-commit-msg
commit-msg post-receive pre-commit push-to-checkout
post-applypatch post-rewrite pre-push update
post-checkout post-update pre-rebase
post-commit pre-applypatch pre-receive
Вообще говоря, мы будем делать соответствующие вещи только в два этапа:
-
pre-commit, предварительная локальная фиксация. Обычно перед фиксацией выполняются некоторые проверки синтаксиса и lint. -
pre-push, предварительная удаленная фиксация. Обычно перед этим коммитом запускаются какие-то тесты.
Итак, в нашем интерфейсном проекте мы написали эти дваscripts. Соответствующая реализация выглядит следующим образом:
{
"precommit": "lint-staged",
"prepush": "ng test && ng build --prod"
}
существуетprecommitкогда мы сотрудничаемlint-stagedа такжеprettierСоздать форматирование кода:
"lint-staged": {
"src/app/*.{css,scss}": [
"stylelint --syntax=scss",
"prettier --parser --write",
"git add"
],
"{src,test}/**/*.ts": [
"prettier --write --single-quote",
"git add"
]
}
На самом деле, используяng lint --fixТоже хороший способ.
Впоследствии мы предшествуем push-коду, т.е.prepush, протестировано и Angular создает рабочие скрипты. Поскольку модульные тесты выполняются довольно быстро, их можно выполнить за несколько минут, что позволяет быстро реагировать на проблемы. Вместо того, чтобы ждать, пока возникнет проблема с непрерывной интеграцией, устраните ее.
Но Git улучшает такие параметры, а также предоставляет--no-verifyпараметр. Это позволяет разработчикам отправлять код без вышеуказанной проверки.
Мы часто не можем запретить другим делать это, особенно когда сотрудничает несколько команд.
Непредсказуемые опасные подачи
Первоначально я хотел назвать это «рискованные коммиты», но я думаю, что рискованные коммиты более надежны.
Обычные собираются на ужин, уходят с работы, собираются на встречу и т. д. и перед уходом отправляют код. С самой функцией проблем может и не быть, но она блокирует последовательность последующих действий.
Конечно, когда есть факторы, которые нельзя исключить, например, землетрясения, пожары и т. д., нет необходимости учитывать эти вещи.
Наличие этих спецификаций и методов может помочь нам в разработке более стабильных веб-приложений.
В заключение
Скорость разработки и качество — сложный баланс. В разное время мы должны принимать разные технические решения.