Если я руководитель клиентской группы, как мне сформулировать спецификации для совместной работы?

внешний интерфейс Управление командой
Если я руководитель клиентской группы, как мне сформулировать спецификации для совместной работы?

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


Автор уже давно один воюет на поле фронтенда (подразумевается, что в команде всего один человек), и он - норма. Поскольку бизнес компании расширяется, а некоторые люди расширяются, пришло время задуматься о стандартах совместной работы и кодирования. Эта статья документирует авторскую前端协作规范Некоторые мысли время от времени, я надеюсь принести некоторую помощь и вам.

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


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


CHANGELOG


серия статей


Что такое спецификация?

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


Зачем нужна норма?

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

Что содержит спецификация?

Как следует из названия статьи,Спецификация фронтенд-сотрудничества относится не только к «спецификации кодирования», эта спецификация включает все аспекты фронтенд-разработки., такие как управление базой кода, совместная работа с интерфейсом и сервером, спецификация кода, спецификация совместимости;

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


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


1 Спецификация рабочего процесса

1.1 Развитие

1.1.1 Спецификация версии

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

  • Основной номер версии: когда вы вносите несовместимые изменения API,
  • Второстепенный номер версии: когда вы добавляете функции, совместимые с предыдущими версиями,
  • Номер редакции: когда вы вносите исправления для проблем обратной совместимости.

⬆️ вернуться к началу

1.1.2 Спецификации системы контроля версий

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

Наиболее популярные модели/рабочие процессы ветвления git:git-flow, но большинство команд разработает свои собственные спецификации рабочего процесса git в соответствии со своей ситуацией, например, наша командаспецификация филиала

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

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

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

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


⬆️ вернуться к началу

1.1.3 Спецификация информации о представлении

Хорошо организованное сообщение коммита может улучшить общее качество проекта и имеет как минимум следующие преимущества:

  • Информация об отправке в едином формате помогает автоматизировать генерацию CHANGELOG.
  • Репозиторий — это не просто репозиторий для хранения кода, он записывает журнал разработки проекта, и он должен четко выражать, что делал этот коммит., Эти записи должны помочь опоздавшим изучить код и быстро просмотреть его, а также облегчить другим участникам проверку кода.
  • Нормализация информации о коммите может помочь коммиттеру отправлять осмысленные, хорошо детализированные «коммиты»., Коммиттер должен придумать, как описать фиксацию, что пассивно побуждает его взять на себя управление.Детализация фиксации

Более популярная в сообществе спецификация сообщения коммита:Спецификация сообщения коммита Angular, кроме этого, они также довольно хороши:


Кроме того, эти инструменты могут помочь вам проверить сообщения фиксации и сгенерировать CHANGELOG:

  • conventional-changelog- Генерация CHANGELOG и выпуск информации из информации о коммите проекта.
  • commitlint- Информация о подаче инспекции
  • commitizen- 🔥Простая спецификация фиксации и инструмент помощи при фиксации, рекомендуется
  • standard-changelog- Инструмент командной строки фиксации в стиле Angular

⬆️ вернуться к началу

1.2 Спецификации сборки

Для команд или сценариев нескольких проектов, которые необходимо поддерживать, очень важна унифицированная цепочка инструментов сборки.Этот набор инструментов должен подчеркивать «соглашение, а не конфигурацию», позволяя разработчикам больше сосредоточиться на развитии бизнеса.. Автор находится впредставлены в статьеvue-cli3В обновлении много важных моментов, и оно идеально подходит в качестве основы для создания наборов инструментов для команд:

  • Прежде всего, этот тип инструмента должен уважать «соглашение, а не конфигурацию».. То есть по их спецификациям его можно использовать из коробки и быстро развивать бизнес.Это очень важно при командной работе, и мы не рекомендуем членам команды заботиться о вонючей и долгой конфигурации сборки вебпака
  • vue-cli3отстраниласьcli service层, тулчейн можно обновлять самостоятельно. Это означает, что сценарии и конфигурация сборки проекта хранятся в отдельном проекте службы, а не имеют конфигурацию и зависимости веб-пакета в каждом каталоге проекта, как раньше.Преимущество этого заключается в том, что можно независимо и просто обновить всю цепочку сборки.
  • Гибкий механизм плагинов. Пользовательские сборки для команд должны быть инкапсулированы в плагины, которые также можно обновлять независимо.

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

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

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

  • create-react-app- 🔥Начать разработку React с нулевой конфигурацией
  • vue-cli- 🔥Нулевая конфигурация, CLI сборки проекта с прогрессивным улучшением
  • parcel- Инструмент для упаковки веб-приложений с нулевой конфигурацией
  • Fusebox- Высокоскоростной и простой в использовании инструмент для упаковки
  • microbundle- Нулевая конфигурация, основанная на Rollup, подходящая для упаковки «библиотек»

⬆️ вернуться к началу

1.3 Спецификации рабочего процесса публикации

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

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

  • изменение кода
  • Зафиксировать изменения кода в удаленном репозитории
  • Программа проходит тесты CI (например, Трэвис становится зеленым)
  • Поднимите версию в package.json
  • Создать журнал изменений
  • Отправьте файлы package.json и CHANGELOG.md
  • Ярлык
  • толкать

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


⬆️ вернуться к началу

1.4 Непрерывная интеграция

После того, как весь рабочий процесс разработки определен, его можно использовать持续集成服务автоматизировать весь процесс. Например, типичный процесс CI:

Что такое непрерывная интеграция и что она означает??

мы должны持续集成Разделить на два слова, чтобы понять, что такое持续? что集成?

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

Чтобы взять простой пример,Например, проверка кода, «непрерывная» проверка кода заключается в проверке кода, как только код изменяется (например, при сохранении или проверке IDE в реальном времени или при отправке в репозиторий), в то время как «непостоянная» проверка кода после завершения всего кодирования. , а затем проверьте. Сравнивая эти два метода, можно обнаружить, что непрерывная проверка кода позволяет обнаруживать ошибки как можно раньше, а ошибки легче понять и справляться с ними. на тысячу миль, переплетенные, они в конце концов станут неуправляемыми.

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

Так что же такое «интеграция»?? Узкую интеграцию можно просто рассматривать как«Интеграционное тестирование»Итак, интеграционное тестирование может выполнять статическое тестирование кода, модульное тестирование, интеграционное тестирование после прохождения модульного тестирования и запуск E2E-тестирования в смоделированной среде после того, как приложение будет сформировано в целом. То есть здесь выполняется серия автоматизированных тестов для проверки программной системы.

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

OK, Объясните, почему непрерывная интеграция дает преимущества:

  • Находите ошибки на ранней стадии и пробуйте их быстро. Чем раньше выявляются ошибки, тем дешевле их устранять
  • Автоматизируйте рабочие процессы и сократите ручное вмешательство. Люди более подвержены ошибкам, чем машины, а машины хорошо справляются с повторяющимися задачами.

Обычно они определяются для спецификаций непрерывной интеграции.:

  • Среда выполнения, например контейнер, версия Node, операционная система и т. д.
  • триггерное состояние. Например, триггер по времени, какую ветвь запускать, какая задача будет запущена и т. д.
  • выполненные задачи
  • Разделите этапы непрерывной интеграции, например
    • Проверить: включая модульные тесты и проверку кода. Весь код, отправленный в репозиторий, будет выполняться на этом этапе. Как правило, вы можете пропустить этот этап, указав [ci skip] в заголовке отправки
    • Сборка: сборка внешнего проекта. Только ветвь фиксации или выпуска с тегом версии будет запускать задачу сборки.
    • Выпуск: доставить/выпустить результат сборки внешнего интерфейса. Только ветвь фиксации или выпуска с тегом версии запустит задачу выпуска после успешной сборки.
  • Определение шаблонов сценариев непрерывной интеграции

Часто используемые службы CI:


расширять


⬆️ вернуться к началу

1.5 Управление задачами

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

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

Тогда же был сделан проект«Правила внедрения Канбана», так что управление задачами тоже немного опыта.

Поговорим о некоторых полезных инструментах:

  • Выпуск канбан- Управление задачами может осуществляться на основе Gitlab или Github Issue, оба из которых поддерживают Kanban. Очень гик, рекомендую
  • Tower- Специализируется на управлении задачами Канбан. Небольших команд в принципе достаточно. Мы используем этот продукт сейчас
  • teambition- Аналогичен башне, но не используется в глубине.
  • Trello- Хорошо выглядит.

⬆️ вернуться к началу


2 Спецификация стека технологий

Передний стек технологий компании, в которой сейчас находится автор, раньше был очень хаотичным.Три фреймворка: Vue, React и AngularJS, да и стили тоже очень разные.На тот момент хотелось взять пакет и уйти За судьбой нестандартного стека технологий можно обратиться к индийскому самолету:

Немногие люди владеют этими тремя фреймворками, не говоря уже о команде.

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

Таким образом, эффективность разработки команды основана на стабильном и квалифицированном стеке технологий.. Стабильная спецификация стека технологий способствует совместной работе и общению в команде; кроме того, если команда владеет этим стеком технологий, это будет относительно легко, когда возникают проблемы или требуется глубокая настройка.

Спецификация внешнего стека технологий в основном включает следующие типы:

  • Язык программирования — TypeScript или Javascript.
  • Фреймворк пользовательского интерфейса и поддерживающая его экология, а также альтернативы. Экология за ним огромна:
    • Фреймворк пользовательского интерфейса
    • маршрутизация
    • государственное управление
    • Библиотека компонентов
    • глобализация
    • анимация
    • рендеринг на стороне сервера
    • Строительные леса, инструменты CLI
    • тестирование компонентов
  • Стиль: содержит соглашения об именах, препроцессоры, методологию и многое другое.
  • анимационный движок
  • QA. Включает тестирование, lint, инструменты форматирования, мониторинг
  • Инструмент сборки проекта, например, webpack, vue-cli.
  • менеджер пакетов. нпм, пряжа
  • инструменты управления проектами
  • обработка времени. Например Moment.js
  • шаблонизатор
  • Инструменты разработки
  • Фреймворк разработки бэкенда
  • Библиотека инструментов
  • Инструменты разработки/отладки
  • так далее

Проверьте нашу командуСпецификация стека технологий


⬆️ вернуться к началу

2.1 Технический отбор

Как стандартизировать стек технологий команды с нуля, или как подбирать модели?? Например, чтобы сначала определить варианты, следует ли сейчас выбрать Vue или React (тема, которая может вызвать разногласия)?

Буквально на днях на SegmentFault был дан ответ на вопрос:, я говорил об одном из нашихМного лет назадПример того, как решить, использовать ли React или Vue (обратите внимание, что результат не имеет значения!):


Эта статья очень хорошо написана и вдохновила меня. В сочетании с примерами приведенных выше ответов, давайте поговорим о некоторых методах (элементах оценки) для выбора связанных технологий:

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

    Одна из причин, по которой наша команда наконец выбрала React, заключается в том, что мы знакомы с ним, он хорошо работает в нескольких существующих приложениях, поэтому React + 1

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

    В приведенном выше примере это также упоминалось: несколько лет назад экология React была сильнее, чем Vue, поэтому React + 1

  • Выберите технологию стадии роста.В нем есть предложение: «Минимальный критерий выбора технологии — жизненный цикл технологии должен быть значительно больше, чем жизненный цикл проекта».

    Технология, которую мы выбираем, должна быть перспективной и ориентированной на будущее, что является основным принципом выбора. Поэтому мы обычно не выбираем такие «устаревшие» технологии, какAngularJS(1.х),Backbone, Поскольку сейчас есть лучшие варианты, не будьте слишком консервативны.

    «Вперед» также означает, что лидер должен быть в состоянии предсказать будущее направление технологии.Здесь много опорных факторов, таких как поддержка крупных заводов, текущая активность сообщества, деятельность по разработке и т. д.

    React и Vue очень мотивированы, например, недавний React Hook React и будущий ConcurrentMode, асинхронный рендеринг... На данный момент Vue и React связаны

  • Стабильность API. Типичными примерами являются Angular и Python.Нестабильный API приведет к фрагментации сообщества, а также приведет к более высоким затратам на обновление проекта или невозможности обновления, что в конечном итоге станет техническим долгом.

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

    На данный момент React и Vue все еще связаны

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

    Это зависит от использования команды. Например, наша команда использует Typescript единообразно. Использование Vue с Typescript не идеально, поэтому React + 1

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

    Типичный пример — пожар, охвативший весь мир 10 лет назад.Rails, Использует ли бэкэнд традиционные бэкенд-технологии Rails или Java/C#/PHP?Многие стартапы (такие как Github, Gitlab, Twitter) выбирают первое, им нужно быстро разработать прототипы и быстро занять рынок, разработка на Rails очень крутая и быстрая , этот тип выбора соответствует «потребностям бизнеса».

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

    Например, в упомянутом выше React Native мы рассматривали возможность применения технологии React Native на мобильной стороне для реализации кроссплатформенности клиента — это влияние на бизнес. В это время нужно ли React снова +1?Аналогично что такое серверный рендеринг,бессерверный и т.д., я ожидаю, что статус фронтенда будет становиться все выше и выше

В общем, React выигрывает в этом случае.

расширение:


⬆️ вернуться к началу

2.2 Использование новых технологий

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

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

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


⬆️ вернуться к началу


3 Спецификации совместимости браузера

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

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


3.1 Определение совместимых стратегий

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

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


⬆️ вернуться к началу

3.2 Определение оценок браузера

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

  • Полностью совместим: Убедитесь, что функция 100% нормальная.
  • Частично совместим: Это может только гарантировать, что функции, стиль и требования будут примерно одинаковыми. Для некоторых багов, не влияющих на основные требования и функции, приоритет будет снижен или не обработан.
  • несовместимый: независимо от совместимости

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

В качестве примера вот наша спецификация совместимости для систем управления:


⬆️ вернуться к началу

3.3 Получить статистику


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

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


Общая статистика браузера может быть получена из этих мест:


Определить, поддерживает ли браузер функцию:


⬆️ вернуться к началу


4 Спецификации организации проекта

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

4.1 Общие нормы организации проекта

Типичная спецификация проектной организации выглядит следующим образом:

  • README.md: Описание предмета, это самое важное. Вы должны предоставить ключевую информацию о проекте или ввод связанной информации здесь.Как правило, включают следующую информацию:

    • Краткое описание, основные особенности проекта
    • Операционная среда/зависимости, установка и сборка, руководство по тестированию
    • Простой пример кода
    • Документ или запись документа, другая версия или связанная запись ресурса
    • контакты, дискуссионная группа
    • Лицензирование, рекомендации по вкладу/разработке

  • CHANGELOG.md: Поместите содержимое каждого изменения версии, обычно для описания содержимого каждого изменения версии. Удобные пользователи определяют, какую версию следует использовать.keep a changelog

  • package.json: Интерфейсный проект должен быть.Опишите текущую версию,Доступные команды, имя пакета, зависимости, ограничения среды, конфигурация проекта и другая информация.

  • .gitignore: игнорировать ненужные файлы и избегать фиксации автоматически сгенерированных файлов в репозиторий.

  • .gitattributes: конфигурация git, здесь могут потребоваться некоторые межплатформенные различия, например правила новой строки.

  • docs/: Подробная документация проекта, опционально.

  • examples/: Пример кода для проекта, необязательно.

  • build: Здесь размещается скрипт класса инструмента проекта, не обязательный. При использовании инструментов сборки единства этот каталог отсутствует.

  • dist/: Каталог вывода результатов сборки проекта.

  • src/: каталог исходного кода

  • tests/: Каталог модульных тестов.JestТехнические характеристики,__tests__Каталог обычно находится в том же родительском каталоге, что и тестируемый модуль, например:

    /src
  __tests__/
    index.ts
    a.ts
  index.ts
  a.ts

  • tests: глобальный тестовый каталог, обычно для тестов интеграции приложений или тестов E2E и других вариантов использования.

  • .env*: В проекте мы обычно используем环境变量влиять на поведение приложения в различных операционных средах. Это можно сделать с помощьюdotEnvдля чтения переменных окружения из файла. Обычно файлов три:

    • .envОбщие переменные среды
    • .env.developmentпеременные окружения для среды разработки
    • .env.productionПеременные среды для среды сборки

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


Для проектов с открытым исходным кодом обычно также включают эти каталоги:

  • LICENSE: Описание Лицензия проекта
  • .github: Спецификации и рекомендации по открытию исходного кода
    • ВКЛАД: Руководство по вкладу, которое в целом описывает спецификацию вклада, а также основную организацию и структуру проекта.
    • CODE_OF_CONDUCT: Кодекс поведения
    • COMMIT_CONVENTION: Спецификация информации фиксации, упомянутая выше.
    • ISSUE_TEMPLATE: шаблон задачи, github может автоматически распознавать этот шаблон.
    • PULL_REQUEST_TEMPLATE: шаблон PR

Например, любой хороший проект с открытым исходным кодом — ваш учитель.React,Vue...


⬆️ вернуться к началу

4.2 Стили организации каталогов

Вышеприведенное является лишь общей спецификацией организации проекта, то, как организован конкретный исходный код, также зависит от используемого вами стека технологий и предпочтений команды. В интернете много туториалов, подробности можно поискать怎么组织XX项目Подводя итог, можно выделить три основных стиля организации проекта:

  • Rails-style: Разделить на разные каталоги в зависимости от типа файла, напримерcomponents,constants,typings,viewsЭто происходит из среды Ruby-on-Rails, которая разделяет различные типы каталогов в соответствии с архитектурой MVC.Типичная структура каталогов выглядит следующим образом:

      app
    models # 模型
    views # 视图
    controllers # 控制器
    helpers # 帮助程序
    assets  # 静态资源
  config     # 配置
    application.rb
    database.yml
    routes.rb      # 路由控制
    locales        # 国际化配置
    environments/
  db        # 数据库相关

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

    Users/
Home/
  components/
  actions.js
  actionTypes.js
  constants.js
  index.js
  model.js
  reducer.js
  selectors.js
  style.css
index.js
rootReducer.js

  • Ducks-style: Преимущество похоже на доменный стиль, но более тщательный, он обычно определяет связанные элементы в одном файле. Типичным примером является однофайловый компонент Vue, но Vuex также использует этот стиль:

    <template>
  <div id="app">
    <h1>My Todo App!</h1>
    <TodoList/>
  </div>
</template>

<script>
import TodoList from './components/TodoList.vue'

export default {
  components: {
    TodoList
  }
}
</script>

<style lang="scss">
@import './variables.scss';
/* ... */
</style>

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

src/
  components/      # 🔴 项目通用的‘展示组件’
    Button/
      index.tsx    # 组件的入口, 导出组件
      Groups.tsx   # 子组件
      loading.svg  # 静态资源
      style.css    # 组件样式
    ...
    index.ts       # 到处所有组件
  containers/      # 🔴 包含'容器组件'和'页面组件'
    LoginPage/     # 页面组件, 例如登录
      components/  # 页面级别展示组件，这些组件不能复用与其他页面组件。
        Button.tsx # 组件未必是一个目录形式，对于一个简单组件可以是一个单文件形式. 但还是推荐使用目录，方便扩展
        Panel.tsx
      reducer.ts   # redux reduces
      useLogin.ts  # (可选)放置'逻辑', 按照👆分离逻辑和视图的原则，将逻辑、状态处理抽取到hook文件
      types.ts     # typescript 类型声明
      style.css
      logo.png
      message.ts
      constants.ts
      index.tsx
    HomePage/
    ...
    index.tsx      # 🔴应用根组件
  hooks/           # 🔴可复用的hook
    useList.ts
    usePromise.ts
  ...
  index.tsx        # 应用入口, 在这里使用ReactDOM对跟组件进行渲染
  stores.ts        # redux stores
  contants.ts      # 全局常量

Чиновники Framework редко вмешиваются в организацию проекта. Читатели могут обратиться к следующим ресурсам, чтобы установить свои собственные нормы организации проекта:


⬆️ вернуться к началу

4.3 Леса и шаблоны проектов

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

связанные ресурсы:

  • yeoman- Ветеран строительных лесов
  • plop- Вспомогательный интерфейс командной строки для генерации кода
  • hygen- похоже на шлепок
  • generact- Создавайте компоненты React, файловая структура большинства компонентов похожа, этот инструмент поможет вам сгенерировать эти повторяющиеся коды.
  • babel-code-generator- Используйте babel для более продвинутого редактирования кода и автоматической генерации

⬆️ вернуться к началу


5 Спецификации кодирования

Большинство «внешних спецификаций» в Интернете относятся к спецификациям кодирования, которые являются «узкими» внешними спецификациями.

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

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

Современные инструменты Lint уже настолько продвинуты, что ограничивают практически любое поведение при написании кода., Такие как ограничения на длину файла, сложность функций, соглашения об именах и аннотациях, черные списки интерфейсов, DeadCode, проверка на наличие простых логических ошибок...

У каждого программиста свое мнение о «хорошем коде».Единый стандарт кодирования позволяет избежать ненужных дебатов и споров, подобных тому, как Цинь Шихуан объединил Воюющие царства.


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


5.1 Javascript

  • Линттулс
    • ESLint- 🔥В настоящее время это самый популярный и общий инструмент Javascript Lint в сообществе, Babel в мире Lint. Поддержка пользовательских плагинов, пресетов. Если вы не хотите бросать, вы можете выбрать некоторые из его предопределенных конфигураций.
    • TSLint- Инструмент Typescript Lint. Но скорозаброшенный, ESLint рекомендуется
  • Технические характеристики
    • JavaScript Standard Style- 🔥 Нулевая конфигурация, "стандартная" спецификация кодирования Javascript.Нижний уровень основан на Eslint. Машинописный текст в настоящее время не поддерживается
    • Airbnb JavaScript Style Guide- Стандарт кодирования Airbnb, отраслевой эталон
  • Проверка типов. На данный момент они сгруппированы здесь, поскольку относятся к одному и тому же«статический тест»
    • Typescript- 🔥 Дополнение к языку Javascript, который является «новым» языком, а не простой проверкой типов.он также поддерживаетПроверка типов в родном Javascript
    • Flow- Проверка типов от Facebook, синтаксис аналогичен Typescript, лично рекомендую использовать Typescript

⬆️ вернуться к началу

5.2 HTML


⬆️ вернуться к началу

5.3 CSS

  • Линттулс
    • stylelint- 🔥 Универсальный инструмент проверки кода CSS, поддерживающий новейший синтаксис CSS, CSS-in-js и другие синтаксисы, подобные CSS (такие как SCSS, Less), а также предопределенные конфигурации, рекомендуется использовать
  • Технические характеристики
  • Методология
    • BEM- 🔥 Соглашение об именах БЭМ
    • OOCSS
    • smacss

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


⬆️ вернуться к началу

5.4 Форматирование кода

  • Prettier- 🔥 Пусть все дело в форматировании кода!

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


⬆️ вернуться к началу

5.5 Интегрированный


⬆️ вернуться к началу

5.6 Руководства по стилю для конкретных фреймворков


⬆️ вернуться к началу

5.7 Code Review

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

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

  • Принципы программирования, дизайн-мышление.Например, в соответствии с принципами SOLID?Достаточно ли DRY? Является ли дизайн интерфейса простым и легко расширяемым,
  • Степень сопряжения модулей, дублирование кода
  • Надежность кода. Есть ли утечка памяти, является ли он потокобезопасным, есть ли потенциальные проблемы с производительностью и исключения, обрабатываются ли ошибки
  • Производительность и эффективность кода.
  • Есть ли сценарии, которые не были рассмотрены?

Если вы внедряете проверку кода впервые, вы можете создать контрольный список для проверки. После того, как я стал опытным, в моем сердце не осталось кода.


Обзор кода имеет много преимуществ, таких как:

  • Проверка кода позволяет другим участникам ознакомиться с кодом.. Это гарантирует, что другие смогут быстрее взять на себя вашу работу или помочь вам решить определенные проблемы.
  • Улучшить качество кода. Без сомнения, с одной стороныинициативаНапример, если ваш код нуждается в рецензировании, это сознательно улучшит качество кода настолько, насколько это возможно; с другой стороны, другие участники могут проверить качество кода отправителя.
  • Проверьте или улучшите уровень программирования новых участников. При обучении новых людей, поскольку мы не доверяем коду, который они присылают, мы проводим проверку, чтобы проверить, проходит ли код тест. С другой стороны, это реальный кейс, который позволяет быстро улучшить свои способности.

Есть два способа проверки кода: один提交时,один定时:

  • 提交时, Большинство проектов с открытым исходным кодом используют этот подход. С точки зрения непрофессионала, это запрос на слияние. В официальный репозиторий может быть добавлен только тот код, который прошел тесты и проверки другими участниками. Этот подход также известен как «блокирующая» проверка кода и обычно используется с GitFlow.
  • 定时, В конце проекта, на определенной вехе проекта или в фиксированное время (каждый день, каждую неделю...) Члены команды собираются вместе, чтобы проверить код, который они написали, и позволить другим членам проверить

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

а также提交时ReviewВы можете ориентироваться на новичков, например, если вы не доверяете их коду или хотите помочь им улучшить свои навыки кодирования.


связанные ресурсы:


⬆️ вернуться к началу


6 Спецификации документа

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

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

Под документом в широком смысле понимается не только сам «документ», он имеет множество форм, источников и носителей, которые могут описывать знание, а также процесс формирования и повторения знания.. Например, записи о представлении кода репозитория, комментарии к коду, записи решений и обсуждений, CHANGELOG, пример кода, спецификации, традиционные документы и т. д.


6.1 Создание центра документации

Наша компания занимается обменом мгновенными сообщениями, поэтому до того, как мы использовали «собственные» средства связи для обмена документами, с этим методом были большие проблемы:

  1. Если нет привычки к архивированию (например, документация по внутреннему API, поскольку она поддерживается серверной частью и, как правило, активно не архивируется), документ может быть утерян, и средство связи не сохранит ваш документ на постоянной основе. . Когда файл потерян, его необходимо повторно запросить у сопровождающего документа.
  2. Плохо то, что сопровождающий документа также вручную архивирует его локально, что приводит к проблеме: если работа передана, другим разработчикам нужно потратить немного времени, чтобы найти ее, если она потеряна, ее действительно нет.
  3. Каждый раз, когда документ обновляется, его необходимо перевыпускать, что очень хлопотно и может быть пропущено, что приведет к несоответствиям.
  4. Изучение знаний, а также содержательные обсуждения не могут быть заархивированы.

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

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

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

Текущий план нашей компанииGit+Markdown, что означает, что вся документация находится в репозитории git. Коммерческие решения также рассматривались ранее, такие какДокументация по графиту,Документация Тенсент, но руководство не доверяет этим сервисам.

Общая организация проекта git выглядит следующим образом:

规范/
A应用/
  产品/
  设计/
  API文档/
  测试/
  其他/
B应用/

Репозитории Git (такие как Gitlab) имеют много преимуществ, таких как отслеживание истории, управление версиями, обсуждение проблем (вы можете связать проблемы или коммиты), совместная работа нескольких человек, поиск и управление разрешениями (настройка для разных репозиториев или групп для разных людей). ) разрешения) и т. д..

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

такGit+MarkdownОн не может удовлетворить различные потребности в обработке документов, таких как интеллект-карты, диаграммы, таблицы, PPT, доски и т. д. В конце концов, это не профессиональный инструмент для обработки документов. Поэтому для сценариев с большим количеством требований к документам, таких как продукты и дизайнеры, документы обычно управляются традиционными способами или с помощью более профессиональных инструментов.


⬆️ вернуться к началу

6.2 Формат документа

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

Следующие инструменты могут повысить эффективность разработки Markdown:

  • Визуальный редактор
    • Visual Code: большинство редакторов кода поддерживают редактирование и предварительный просмотр Markdown.
    • Mou: Старый редактор под Mac
    • typora: Кроссплатформенный редактор Markdown, рекомендуется
  • markdownlint: проверка кодировки
  • Расширение (код Visual Studio):
    • Markdown All in One: All you need to write Markdown (keyboard shortcuts, table of contents, auto preview and more)
    • Markdown TOC: генерация каталога уценки, мой наиболее часто используемый плагин уценки
  • Инструменты рисования диаграммы:
    • drawioВеб-инструмент для построения диаграмм, а также автономный клиент
    • KeyNote/PPTВременный рисунок тоже хорош

⬆️ вернуться к началу

6.3 Шаблоны для определения документов

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

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

Например, для документации API может потребоваться следующее:

  • индекс интерфейса
  • Версия интерфейса, изменить запись
  • Использование и общее описание, аутентификация и т. д.
  • Опишите конкретный интерфейс
    • Описание функции
    • имя метода или URI
    • Определения параметров и возвращаемых значений
    • пример вызова
    • Заметки и т. д.

Конкретное содержание спецификации варьируется от команды к команде, поэтому нажмите здесь.


расширение:


⬆️ вернуться к началу

6.4 Обсуждение как документация

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

Поэтому, по сравнению с использованием IM, автор рекомендует режим связи Issue, потому чтоЭто облегчает организацию архива, индексирование и поиск. И дискуссия на IM, как проточная вода, ушла навсегда.

Конечно, сценарии применения двух инструментов различаются.Если вы используете IM для использования Issue, Issue станет очень водянистым.Вопросы подходят для содержательных и целенаправленных дискуссий. Так что осудите разработчиков, которые поливают водой Github Issue.

Есть много замечательных применений для Issue, рекомендуется прочитать эту статью.

Теперь многие проекты с открытым исходным кодом ввели процесс RFC (запрос на комментарии) (ссылкаReact принимает новый процесс RFC, так же какСамый мрачный день Вью), что дает разработчикам ощущение «передачи крепостного и быть хозяином дома», и любой может участвовать в принятии решений крупных событий в проекте с открытым исходным кодом.Каждый RFC будет описывать мотивацию решения, детальный план, сильные и слабые стороны. Помимо официальной документации, эти RFC являются ценными учебными материалами..

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

Полезен ли Issue для разработки корпоративных приложений?

Конечно полезно, например мы можем перенести такую ​​тему из IM в Issue:

  • Дизайн
  • решение/совет
    • Внедрение новых функций и новых технологий
    • рефакторинг
    • оптимизация производительности
    • Технические характеристики
  • обсуждение проблемы
  • Главное событие
  • планирование или отслеживание прогресса
  • ...

Кроме того, Проблемы обычно классифицируются по тегам, что удобно для систематизации и поиска:


⬆️ вернуться к началу

6.5 Комментарии являются документацией

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

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


⬆️ вернуться к началу

6.6 Код как документация

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

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

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

import * as React from 'react';
import { Component } from 'react';

/**
 * Props注释
 */
export interface ColumnProps extends React.HTMLAttributes<any> {
  /** prop1 description */
  prop1?: string;
  /** prop2 description */
  prop2: number;
  /**
   * prop3 description
   */
  prop3: () => void;
  /** prop4 description */
  prop4: 'option1' | 'option2' | 'option3';
}

/**
 * 对组件进行注释
 */
export class Column extends Component<ColumnProps, {}> {
  render() {
    return <div>Column</div>;
  }
}

Соответствующие инструменты:

  • Документация API
    • Typescript
      • tsdocОфициальный стандарт документации аннотаций машинописного текста
      • typedocГенератор документации на основе стандарта tsdoc
    • Javascript
      • jsdocСтандарт и генератор комментариев к документации Javascript
  • Документация по внутреннему интерфейсу
    • SwaggerСпецификация документа интерфейса Restful
    • GraphQL: для этого существует множество инструментов, таких какgraphiql, интегрированный с Playground и документацией, очень продвинутый
    • Easy MockСервис, который визуализирует и быстро генерирует смоделированные данные
  • Документация по компонентам
    • StoryBookОбщие инструменты разработки компонентов, тестирования, документирования
    • React
    • Vue
      • vue-styleguidist
      • Есть лучшие инструменты, пожалуйста, прокомментируйте и скажите мне

⬆️ вернуться к началу


7 Спецификации дизайна пользовательского интерфейса

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

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

Кратко обобщим значение спецификаций дизайна пользовательского интерфейса:

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

Создание четко определенной спецификации проекта требуетUI设计和开发Тесное сотрудничество, а иногда и наш интерфейс.

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

Если ваша команда не планирует разрабатывать собственные спецификации дизайна пользовательского интерфейса, рекомендуется использовать готовые библиотеки компонентов с открытым исходным кодом:

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


⬆️ вернуться к началу


8 Спецификации испытаний

Тестирование — важное средство обеспечения качества кода, но мало кто хочет тратить на это слишком много времени.

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

ноДля некоторых низкоуровневых модулей с общим кодом по-прежнему необходимо тестировать.

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


Среди них фронтенд-разработчикам необходимо обратить внимание на следующие типы тестов:

  • модульный тест: для тестирования отдельных программных модулей
    • Тестирование UI-компонентов: включает тест Snapshot
  • Интеграционное тестирование: на основе модульного тестирования объединяйте модули для проверки их компонуемости.
  • E2E-тестирование: протестируйте приложение, имитируя реальных пользователей в полной и реальной операционной среде.В основном проверяйте координацию фронтенда и бэкэнда
  • Тест на совместимость: Спецификация совместимости браузера указана выше. Перед отправкой версии для тестирования/выпуска необходимо убедиться, что требования совместимости соблюдены.
  • Тестирование производительности: тестирование и анализ проблем с производительностью
  • разное:
    • Тест на безопасность
    • SEO-тестирование

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

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


8.1 Процесс тестирования

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


⬆️ вернуться к началу

8.2 Модульное тестирование

Есть много юнит-тестоввыгода, Например:

  • Повышение уверенности, адаптация к изменениям и повторение, Если существующий код имеет относительно полные модульные тесты, при рефакторинге кода можно проверить, работает ли модуль. Если изменение вызывает ошибки, модульные тесты также могут помочь нам быстро найти и исправить ошибки.
  • Модульное тестирование — основа интеграционного тестирования.
  • Тестирование — это документация. Если документация не решает вашу проблему, просмотрите модульные тесты, прежде чем планировать просмотр исходного кода. С помощью этих тестовых примеров разработчики могут интуитивно понять базовый API программного модуля.
  • Улучшить качество кода. Код, который легко тестировать, в целом хороший код

Измерить что?

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


руководство по тестированию:

  • Рекомендуемая нефтьUnit Testing Guidelines, обобщает 27 рекомендаций по модульному тестированию, которые очень полезны.
  • Кроме того, в «Руководстве по разработке Java для Alibaba» кратко изложеныРуководство по модульному тестированию, тоже хорошо, хотя название Java, рекомендации общие.

метрики юнит-тестов:

Общее использование测试覆盖率Для количественной оценки, хотя больше споров о том, может ли охват измерять эффективность модульных тестов.

В большинстве случаев рекомендуется максимально увеличить охват, например,语句覆盖率达到70%；核心模块的语句覆盖率和分支覆盖率都要达到100%, Зависит от ситуации в команде

расширение:


Связанные инструменты

  • Безголовые браузеры. Безголовые браузеры являются важной средой выполнения для автоматизации веб-страниц. Обычно используется в функциональном тестировании, модульном тестировании, веб-сканере.
  • тестовая среда
    • Jest🔥Среда модульного тестирования Facebook. Нулевая настройка, поддержка моментальных снимков компонентов, модуль Mock, Spy. В общих сценариях просто изучите один из них для модульного тестирования.
    • Intern
  • модульный тест
  • Библиотека утверждений
  • Mock/Stubs/Spies
  • покрытие кода
  • Ориентиры

⬆️ вернуться к началу


9 Спецификации обработки исключений, мониторинга и отладки

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

9.1 Обработка исключений

Обобщено в Спецификация обработки исключенийОбработка исключений в JavaScript также очень полезна, например:

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

Затем, в соответствии с характеристиками обработки исключений самого JavaScript, суммируются некоторые стандартизированные поведения, например:

  • Не бросайте объекты, не являющиеся ошибками
  • Не игнорируйте асинхронные исключения
  • Глобальный мониторинг исключений Javascript
  • ...

ресурс:


⬆️ вернуться к началу

9.2 Журналы

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

Но обычно мыДо тех пор, пока это необходимо, сохраняется содержательный вывод журнала., например, вы не должны помещать console.log в функцию рендеринга React или в цикл,Информация журнала в стиле DDos не может помочь нам найти проблему, но повлияет на производительность операции.Таким образом, необходима спецификация для ограничения поведения вывода журнала, например:

  • Избегайте повторной печати журналов
  • Ведите журнал аккуратно, разделяя уровни журнала. Например, производственная среда запрещает вывод журналов отладки, выборочно выводит информационный журнал;
  • Классифицируйте журналы, используя такие префиксы, как:[User] xxxx
  • Записывайте только важную информацию, которая может помочь вам диагностировать проблему.
  • ...

Расширенные ресурсы

  • debugИнструмент журнала отладки, подходящий для Node.js и браузеров, поддерживает динамическую печать журнала.
  • vConsoleМобильный инструмент отладки

⬆️ вернуться к началу

9.3 Аномальный мониторинг

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


Мониторинг аномалий обычно собирает данные об аномалиях тремя способами:

  1. Глобальный захват. Например, используя window.onerror илиunhandledrejection
  2. Активно сообщайте. Активно сообщайте в try/catch.
  3. отзывы клиентов. Например, всплывающее окно позволяет пользователям заполнять информацию для обратной связи.

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


Нелегко выполнить хорошую работу по внешнему мониторингу исключений, необходимо иметь дело со следующими вещами:

  • Совместимость с браузером.
  • Панировочные сухари. Соберите некоторые подсказки на месте «катастрофы», которые важны для диагностики проблемы. Например, информация о текущем пользователе, версия, рабочая среда, распечатанные журналы, стек вызовов функций и т. д.
  • Переходы стека вызовов. Обычно сжатый и оптимизированный код, работающий в браузере, этот стек вызовов в основном нечитаем, и обычно его необходимо сопоставить с исходным кодом через SourceMap.Вы можете использовать эту библиотеку:source-map
  • Агрегация данных. Внутренняя система мониторинга должна анализировать и агрегировать информацию, сообщаемую внешним интерфейсом.

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

  • Sentry🔥Бесплатного в принципе достаточно
  • FunDebugПлатное улучшение

расширять:


⬆️ вернуться к началу


10 Спецификации для совместной работы с интерфейсом и сервером

Передняя часть — это подразделение сети, и часто она не может существовать без задней части. Так что время взаимодействия с бэкендом самое долгое.

10.1 Спецификация процесса сотрудничества

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

Типичный процесс совместной работы с интерфейсом и сервером выглядит следующим образом:

  1. анализ спроса. Как правило, у участников есть интерфейс и серверная часть, тестирование и продукт. Размещение продукта, публикация требований, получение отзывов о разработке и тестировании и обеспечение согласованного понимания требований всеми участниками.
  2. Обсуждения фронтенд и бэкенд разработки. Обсудите разработку и дизайн приложения, сообщите технические моменты, трудности и вопросы разделения труда.
  3. Документация по дизайну интерфейса. Он может быть разработан на основе передней и задней частей вместе или может быть разработан на основе задней и передней части, чтобы подтвердить, соответствует ли он требованиям.
  4. Параллельное развитие. Front-end и back-end разрабатываются параллельно, на этом этапе front-end может сначала реализовать статическую страницу или смоделировать интерфейс в соответствии с интерфейсным документом, чтобы имитировать стыковку back-end интерфейса.
  5. Перед совместной отладкой от бэкенда требуется хорошенько поработать над тестированием интерфейса
  6. Совместная отладка в реальной среде. Внешний интерфейс передает запрос интерфейса внутреннему сервису для совместной отладки в реальной среде.

⬆️ вернуться к началу

10.2 Спецификация интерфейса

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

Автор не рекомендует, чтобы серверная часть определяла свои собственные стандарты интерфейса, но должна выбрать некоторые общие стандартные формы интерфейса, такие как:

  • RESTful: RESTful в настоящее время является наиболее широко используемой спецификацией дизайна API, которая реализована на основе самого механизма HTTP.

    Автору лично нравится эта спецификация API, но я считаю, что многие разработчики не очень (или не собираются) ее понимать, а разработанный интерфейс далек от того, что я себе представлял. Другими словами, для RESTful трудно достичь консенсуса среди разработчиков, и легко возникают разногласия.

    Поскольку это наиболее широко используемая форма API, в сообществе существует множество инструментов для документирования, тестирования и имитации интерфейсов RESTful.

  • JSONRPCЭто очень простая и понятная спецификация интерфейса. По сравнению с RESTful, я рекомендую это, потому что это просто и не легко не согласиться, и новички могут быстро принять его.

  • GraphQL🔥Более продвинутая и многообещающая спецификация API. Но вам может быть сложно убедить серверную часть использовать этот стандарт вместе с вами.


На что обратить внимание в дизайне интерфейса:

  • Четко различайте, является ли это нормальным или ненормальным, и строго следуйте примитивам исключений интерфейса.Приведенные выше формы интерфейса имеют четкие примитивы исключений, такие как JSONRPC, которые должны возвращаться при возникновении исключения.错误对象Ответ вместо того, чтобы возвращать коды ошибок в обычном теле ответа. Помимо нормализации кодов ошибок, коды ответов HTTP являются хорошим учебным объектом.
  • Явный тип данных. Многие интерфейсы, написанные бэкендом, неотличимы между строками и числами, и в случае компрометации интерфейс должен выполнить специальную обработку этого свойства, что также может быть потенциальной ошибкой.
  • Объясните значение пустых значений. Например, при выполнении операции обновления означает ли нулевое значение сброс или игнорирование обновления?
  • Ответы избегают избыточного вложения.
  • Интерфейс версионирован для обеспечения обратной совместимости. Как мы сказали в «Спецификации семантического управления версиями» выше, для серверной части API является общедоступным интерфейсом. Общедоступный интерфейс должен иметь номер версии, чтобы указать, какие изменения были внесены в описанный в настоящее время интерфейс и совместимы ли ниже. Теперь интерфейсный код может кэшироваться на стороне клиента, например, апплеты. Если серверная часть внесет изменения, это повлияет на этих пользователей.

⬆️ вернуться к началу

10.3 Спецификация документа интерфейса

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

  • номер версии
  • описание документа
  • Точка входа в службу. Например, базовый путь.
  • Тестовый сервер.
  • Простой пример использования
  • Безопасность и аутентификация
  • Определенное определение интерфейса
    • Имя метода или URL-адрес
    • Описание метода
    • Параметры запроса и их описания, тип должен быть указан (тип данных, необязательный и т.д.)
    • Параметры ответа и их описание, тип должен быть указан (тип данных, необязательный и т.д.)
    • Возможные исключения, коды ошибок и описания
    • пример запроса, необязательно

Проблемы, вызванные ручным обслуживанием:

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

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


⬆️ вернуться к началу

10.4 Тестирование интерфейса и моделирование

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

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

Для тестирования интерфейса и моделирования существует идеальная модель, как показано ниже:

Все начинается с четко определенного документа интерфейса, сгенерированногоMock Serverа такжеMock Client, Mock Server предоставляет фиктивные данные внешнему интерфейсу, а Mock Client помогает серверной части тестировать их интерфейсы.

ресурс:

  • RESTful
    • SwaggerЭто самое близкое решение к идеальной модели выше.
    • JSON ServerБыстро сгенерируйте фиктивный сервер JSON
    • Easy MockВизуальный онлайн-сервис имитации интерфейса
  • GraphQl
  • Генерация данных моделирования
    • faker.js🔥Мощный инструмент для генерации данных моделирования, поддерживает Node и браузер
    • Mock.jsСредства генерации данных и моделирования

⬆️ вернуться к началу


11 Обучение/Управление знаниями/Технологические осадки

Я думаю, что управление знаниями в команде очень важно.Что вы хотите спросить у новичка, чтобы он присоединился к команде? Ответ многих людей — «учиться», надеясь, что их технология может быть более сложной, а деньги — на втором месте.

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

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

11.1 Обучение новичков

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

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

  • Процесс разработки продукта: Расскажите о процессах разработки и итерации продукта, а также о сотрудничестве между командами, таких как:

  • Объем работы: Сфера ответственности членов команды

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

  • Технические характеристики: это основная часть этой статьи «Спецификация взаимодействия с интерфейсом». Существуют нормы, которым необходимо следовать, что позволяет участникам начать разработку с более высокой скоростью, снижая при этом затраты на обучение.

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


⬆️ вернуться к началу

11.2 Создайте техническую атмосферу

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

  • Поощряйте участие в проектах с открытым исходным кодом

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

  • Регулярный тематический обмен. Поощряйте членов команды проводить регулярные тематические исследования и исследования, писать технические блоги и делиться результатами своего обучения с другими участниками.Это метод группового обучения, разработанный, чтобы помочь членам команды учиться и расти вместе.

    Например, ветераны-разработчики могут поделиться своим опытом и изучить более глубокие технологии, а новички могут изучить определенные навыки разработки и новые технологии, такие как CSS Grid, svg-анимация и так далее. Рекомендуется, чтобы у членов команды была четкая область обучения, чтобы они могли больше узнать за счет разделения труда и сотрудничества.

    Как возникла тема?

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

  • Внедрение и улучшение спецификаций разработкиСпецификация сама по себе является прямым результатом накопления коллективных знаний.

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

  • Поощряйте рефакторинг и постоянную оптимизацию кода

  • Абстрагируйте набор базовых библиотек или фреймворков, чтобы уменьшить повторяющуюся работу и повысить эффективность работы., Не работайте сверхурочно, начните с повышения эффективности работы


⬆️ вернуться к началу


12 отзывов

Если у вас есть что добавить или прокомментировать, вы можете прокомментировать ниже, чтобы вместе улучшить эту статью, спасибо!

Категории