From 407a2cae9ec5ef472b34a2d803aa0eb169d9025f Mon Sep 17 00:00:00 2001 From: RedrockJS Date: Mon, 10 Mar 2025 15:57:50 +0300 Subject: [PATCH] update team, test --- .../02-classic-layer-based-arch.md | 107 +++++++++- docs/architecture/03-atomic-design.md | 98 ++++++++- .../04-ddd-domain-driven-design.md | 100 +++++++++- .../05-fsd-feature-slice-design.md | 1 + docs/architecture/06-micro-frontend.md | 1 + docs/architecture/07-tdd.md | 1 + docs/team/01-methodology.md | 164 +++++++++++++++ docs/team/01-processes.md | 5 - docs/team/02-methodology.md | 5 - docs/team/02-processes.md | 186 ++++++++++++++++++ docs/testing/01-testing.md | 62 ++++++ docs/testing/index.md | 3 - 12 files changed, 717 insertions(+), 16 deletions(-) create mode 100644 docs/team/01-methodology.md delete mode 100644 docs/team/01-processes.md delete mode 100644 docs/team/02-methodology.md create mode 100644 docs/team/02-processes.md create mode 100644 docs/testing/01-testing.md delete mode 100644 docs/testing/index.md diff --git a/docs/architecture/02-classic-layer-based-arch.md b/docs/architecture/02-classic-layer-based-arch.md index ffec863..2a7aa8d 100644 --- a/docs/architecture/02-classic-layer-based-arch.md +++ b/docs/architecture/02-classic-layer-based-arch.md @@ -2,4 +2,109 @@ sidebar_position: 2 --- -# Классическая архитектура \ No newline at end of file +# Классическая архитектура +Источник: DeepSeek + +Layer-based architecture (архитектура на основе слоёв) — это подход к организации кода, при котором приложение разделяется на несколько логических слоёв, каждый из которых отвечает за определённый аспект функциональности. Этот метод широко используется как во фронтенд-, так и в бэкенд-разработке и помогает создавать структурированные, поддерживаемые и масштабируемые приложения. + +## Основные идеи Layer-based Architecture +1. **Разделение ответственности:** + - Каждый слой отвечает за определённую часть функциональности (например, отображение данных, управление состоянием, работа с API). + - Это упрощает понимание кода и снижает вероятность ошибок. +2. **Изоляция слоёв:** + - Слои взаимодействуют друг с другом через чётко определённые интерфейсы, что делает их независимыми. + - Изменения в одном слое минимально влияют на другие. +3. **Повторное использование:** + - Логика, вынесенная в отдельные слои, может быть переиспользована в разных частях приложения. + +## Основные слои во фронтенд-разработке +1. Presentation Layer (Слой представления): + - Отвечает за отображение данных и взаимодействие с пользователем. + - Включает компоненты, стили и UI-логику. + - Пример: React-компоненты, Vue-компоненты, Angular-шаблоны. +2. Application Layer (Слой приложения): + - Управляет бизнес-логикой приложения. + - Координирует взаимодействие между слоем представления и слоем данных. + - Пример: хуки, сервисы, контроллеры. +3. Data Layer (Слой данных): + - Отвечает за работу с данными: получение, хранение, обновление. + - Включает API-запросы, управление состоянием (например, Redux, MobX), локальное хранилище (localStorage, IndexedDB). + - Пример: Redux slices, GraphQL-запросы, REST API-клиенты. +4. Infrastructure Layer (Инфраструктурный слой): + - Включает вспомогательные функции, утилиты и инструменты, которые используются во всех слоях. + - Пример: хелперы, утилиты, конфигурация приложения. + +Пример структуры проекта с Layer-based Architecture +``` +src/ +│ +├── components/ # Presentation Layer: UI-компоненты +│ ├── Button/ +│ ├── Header/ +│ └── Footer/ +│ +├── pages/ # Presentation Layer: Страницы +│ ├── HomePage/ +│ └── ProfilePage/ +│ +├── hooks/ # Application Layer: Хуки для бизнес-логики +│ ├── useAuth/ +│ └── useCart/ +│ +├── store/ # Data Layer: Управление состоянием (Redux, Zustand) +│ ├── slices/ +│ │ ├── authSlice.ts +│ │ └── cartSlice.ts +│ └── index.ts +│ +├── api/ # Data Layer: Работа с API +│ ├── authApi.ts +│ └── cartApi.ts +│ +├── utils/ # Infrastructure Layer: Утилиты и хелперы +│ ├── formatDate.ts +│ └── validateForm.ts +│ +└── App.tsx # Основной файл приложения +``` + +## Преимущества Layer-based Architecture +1. **Чёткая структура:** + - Код легко понять и поддерживать благодаря разделению на слои. +2. **Упрощение тестирования:** + - Каждый слой можно тестировать изолированно. +3. **Гибкость:** + - Слои можно заменять или модифицировать без влияния на другие части приложения. +4. **Повторное использование:** + - Логика, вынесенная в отдельные слои, может быть переиспользована. + +## Недостатки Layer-based Architecture +1. **Избыточность для небольших проектов:** + - В маленьких приложениях такая структура может показаться излишне сложной. +2. **Зависимость между слоями:** + - Если не соблюдать чёткие границы, слои могут стать слишком связанными. +3. **Сложность настройки:** + - Требуется время и усилия для правильной организации слоёв. + +## Пример взаимодействия слоёв +1. **Presentation Layer:** + - Компонент CartList отображает список товаров в корзине. +2. **Application Layer:** + - Хук useCart управляет логикой корзины. +3. **Data Layer:** + - Redux slice управляет состоянием корзины. +4. **Infrastructure Layer:** + - Утилита для форматирования цены. + +## Когда использовать Layer-based Architecture +- В проектах среднего и крупного размера. +- Когда требуется чёткое разделение ответственности. +- В командах, где разные разработчики работают над разными аспектами приложения. + +Альтернативные подходы +1. **Feature Slice Design:** + - Организация кода вокруг функциональных блоков (фич). + - Подходит для крупных проектов с множеством фич. +2. **Domain-driven Design (DDD):** + - Организация кода вокруг доменных областей (например, `user`, `order`, `product`). + - Часто используется в бэкенд-разработке. \ No newline at end of file diff --git a/docs/architecture/03-atomic-design.md b/docs/architecture/03-atomic-design.md index b8e7ef0..d1c5dcc 100644 --- a/docs/architecture/03-atomic-design.md +++ b/docs/architecture/03-atomic-design.md @@ -2,4 +2,100 @@ sidebar_position: 3 --- -# Atomic design \ No newline at end of file +# Atomic design +Источник: DeepSeek + +Atomic Design — это методология проектирования и организации пользовательских интерфейсов, предложенная Брэдом Фростом (Brad Frost). Она основана на идее разделения интерфейса на небольшие, независимые и переиспользуемые компоненты, которые затем комбинируются для создания более сложных структур. Название методологии вдохновлено химией: так же, как молекулы состоят из атомов, интерфейсы состоят из базовых компонентов. + +## Основные принципы Atomic Design +1. **Иерархия компонентов:** + - Компоненты организуются в иерархию от простых к сложным. + - Каждый уровень иерархии имеет своё назначение и уровень абстракции. +2. **Переиспользуемость:** + - Компоненты проектируются так, чтобы их можно было использовать в разных частях интерфейса. +3. **Модульность:** + - Каждый компонент изолирован и независим, что упрощает тестирование и поддержку. +4. **Масштабируемость:** + - Методология подходит как для небольших, так и для крупных проектов. + +## Уровни Atomic Design +1. Атомы (Atoms): + - Наименьшие и базовые элементы интерфейса, которые нельзя разделить на более мелкие части. + - Примеры: кнопки, инпуты, иконки, текстовые элементы. +2. Молекулы (Molecules): + - Комбинация нескольких атомов, которые вместе выполняют определённую функцию. + - Примеры: форма поиска (инпут + кнопка), карточка товара (изображение + заголовок + цена). +3. Организмы (Organisms): + - Более сложные компоненты, состоящие из молекул и/или атомов. + - Примеры: шапка сайта (логотип + навигация + форма поиска), футер (ссылки + текст + иконки). +4. Шаблоны (Templates): + - Макеты страниц, которые определяют структуру и расположение организмов. + - Пример: шаблон главной страницы (шапка + список карточек товаров + футер). +5. Страницы (Pages): + - Конкретные реализации шаблонов с реальными данными. + - Пример: главная страница сайта с заполненными карточками товаров. + +## Пример структуры проекта с использованием Atomic Design +``` +src/ +│ +├── components/ +│ ├── atoms/ # Атомы +│ │ ├── Button/ +│ │ ├── Input/ +│ │ └── Text/ +│ │ +│ ├── molecules/ # Молекулы +│ │ ├── SearchForm/ # Форма поиска (Input + Button) +│ │ └── ProductCard/ # Карточка товара (Image + Text + Button) +│ │ +│ ├── organisms/ # Организмы +│ │ ├── Header/ # Шапка сайта (Logo + Navigation + SearchForm) +│ │ └── Footer/ # Футер (Links + Text + Icons) +│ │ +│ ├── templates/ # Шаблоны +│ │ ├── HomeTemplate/ # Шаблон главной страницы +│ │ └── ProductTemplate/# Шаблон страницы товара +│ │ +│ └── pages/ # Страницы +│ ├── HomePage/ # Главная страница +│ └── ProductPage/ # Страница товара +│ +└── App.tsx # Основной файл приложения +``` + +## Преимущества Atomic Design +1. **Переиспользуемость:** + - Компоненты можно использовать в разных частях интерфейса, что сокращает дублирование кода. +2. **Масштабируемость:** + - Методология подходит для проектов любого размера. +3. **Упрощение разработки:** + - Чёткая структура помогает разработчикам быстро находить и изменять нужные компоненты. +4. **Согласованность интерфейса:** + - Использование атомов и молекул обеспечивает единообразие дизайна. +5. **Упрощение тестирования:** + - Компоненты можно тестировать изолированно. + +## Недостатки Atomic Design +1. **Сложность для небольших проектов:** + - В маленьких проектах такая структура может показаться излишне сложной. +2. **Требует дисциплины:** + - Необходимо строго следовать принципам, чтобы избежать смешения уровней. +3. **Ограниченная гибкость:** + - В некоторых случаях строгая иерархия может ограничивать возможности кастомизации. + +## Пример реализации Atomic Design +1. **Атом:** Кнопка (Button) +2. **Молекула:** Форма поиска (SearchForm) +3. **Организм:** Шапка сайта (Header) +4. **Шаблон:** Главная страница (HomeTemplate) +5. **Страница:** Главная страница (HomePage) + +## Когда использовать Atomic Design +- В проектах с большим количеством переиспользуемых компонентов. +- Когда требуется высокая согласованность интерфейса. +- В командах, где дизайнеры и разработчики тесно взаимодействуют. + + + + diff --git a/docs/architecture/04-ddd-domain-driven-design.md b/docs/architecture/04-ddd-domain-driven-design.md index 12bc437..ea16068 100644 --- a/docs/architecture/04-ddd-domain-driven-design.md +++ b/docs/architecture/04-ddd-domain-driven-design.md @@ -2,4 +2,102 @@ sidebar_position: 4 --- -# Доменная архитектура \ No newline at end of file +# Доменная архитектура +Источник: DeepSeek + +**Domain-Driven Design (DDD)** — это подход к разработке программного обеспечения, который фокусируется на моделировании бизнес-логики и организации кода вокруг доменных областей (бизнес-контекстов). Хотя DDD изначально был разработан для бэкенд-разработки, его принципы могут быть успешно применены и во фронтенде, особенно в сложных приложениях с богатой бизнес-логикой. + +## Основные концепции DDD +1. **Домен (Domain):** + - Это предметная область, которую решает приложение (например, электронная коммерция, управление проектами, финансы). + - Домен состоит из поддоменов (например, заказы, продукты, пользователи). +2. **Модель (Model):** + - Абстракция, которая описывает ключевые концепции и процессы в домене. + - Модель включает сущности, значения, агрегаты и сервисы. +3. **Ограниченный контекст (Bounded Context):** + - Чётко определённая область, в которой применяется конкретная модель. + - Например, в одном контексте "пользователь" может быть клиентом, а в другом — администратором. +4. **Универсальный язык (Ubiquitous Language):** + - Общий язык, который используется разработчиками, дизайнерами и бизнес-экспертами для описания домена. + - Помогает избежать недопонимания и упрощает коммуникацию. +5. **Слои (Layers):** + - DDD разделяет приложение на слои: доменный слой, слой приложения, инфраструктурный слой и презентационный слой. + +## Применение DDD во фронтенде +Во фронтенде DDD может быть использован для организации кода вокруг бизнес-логики, что особенно полезно в сложных приложениях, таких как CRM-системы, платформы для электронной коммерции или аналитические панели. + +## Основные принципы DDD во фронтенде +1. **Организация кода вокруг доменов:** + - Код структурируется по доменам, а не по техническим слоям (например, `components`, `pages`). + - Каждый домен включает всё необходимое для своей работы: компоненты, логику, состояние, API-запросы. +2. **Изоляция доменов:** + - Домены максимально независимы друг от друга. + - Это позволяет разрабатывать, тестировать и изменять их без влияния на другие части приложения. +3. **Использование универсального языка:** + - Названия компонентов, функций и переменных отражают бизнес-концепции, что делает код более понятным. +4. **Фокус на бизнес-логике:** + - Логика, связанная с доменом, выносится в отдельные модули, что упрощает её тестирование и поддержку. + +Пример структуры проекта с использованием DDD +``` +src/ +│ +├── domains/ # Домены +│ ├── cart/ # Домен "Корзина" +│ │ ├── components/ # Компоненты, специфичные для корзины +│ │ ├── hooks/ # Хуки для корзины +│ │ ├── store/ # Логика состояния (например, Redux slice) +│ │ ├── api/ # API-запросы, связанные с корзиной +│ │ └── index.ts # Экспорт домена +│ │ +│ └── auth/ # Домен "Авторизация" +│ ├── components/ +│ ├── hooks/ +│ ├── store/ +│ ├── api/ +│ └── index.ts +│ +├── shared/ # Общие компоненты и утилиты +│ ├── ui/ # UI-компоненты (кнопки, инпуты и т.д.) +│ └── lib/ # Утилиты и хелперы +│ +├── app/ # Основная логика приложения +│ ├── routing/ # Роутинг +│ ├── providers/ # Провайдеры (например, Redux, Theme) +│ └── index.ts +│ +└── pages/ # Страницы приложения + ├── HomePage/ # Страница "Главная" + └── ProfilePage/ # Страница "Профиль" +``` + +## Преимущества DDD во фронтенде +1. **Чёткая структура:** + - Код организуется вокруг бизнес-контекстов, что делает его более понятным. +2. **Упрощение разработки:** + - Разработчики могут фокусироваться на одной доменной области, не отвлекаясь на остальные части приложения. +3. **Улучшение поддерживаемости:** + - Изменения в одном домене не затрагивают другие. +4. **Гибкость:** + - Домены можно легко добавлять, удалять или заменять. +5. **Тестируемость:** + - Бизнес-логика может быть протестирована изолированно. + +## Недостатки DDD во фронтенде +1. **Сложность для небольших проектов:** + - В маленьких приложениях такая структура может показаться излишне сложной. +2. **Требует глубокого понимания домена:** + - Необходимо тесное взаимодействие с бизнес-экспертами. +3. **Оверхеад:** + - Требуется время и усилия для правильной организации кода. + +## Пример реализации домена "Корзина" +1. Компонент: CartList +2. Хук: useCart +3. Redux slice: cartSlice +4. API: cartApi + +## Когда использовать DDD во фронтенде +В сложных приложениях с богатой бизнес-логикой. +В командах, где разработчики и бизнес-эксперты тесно взаимодействуют. +Когда требуется высокая степень модульности и переиспользуемости. \ No newline at end of file diff --git a/docs/architecture/05-fsd-feature-slice-design.md b/docs/architecture/05-fsd-feature-slice-design.md index 1ffe077..a22c193 100644 --- a/docs/architecture/05-fsd-feature-slice-design.md +++ b/docs/architecture/05-fsd-feature-slice-design.md @@ -3,6 +3,7 @@ sidebar_position: 5 --- # Feature slice design +Источник: DeepSeek **Feature Slice Design (FSD)** — это методология проектирования и организации кода во фронтенд-разработке, которая фокусируется на разделении приложения на независимые, функционально завершённые блоки (срезы), каждый из которых соответствует определённой фиче (функциональности) продукта. Этот подход помогает создавать более структурированные, масштабируемые и поддерживаемые приложения. diff --git a/docs/architecture/06-micro-frontend.md b/docs/architecture/06-micro-frontend.md index ded2c4f..f9556fe 100644 --- a/docs/architecture/06-micro-frontend.md +++ b/docs/architecture/06-micro-frontend.md @@ -3,6 +3,7 @@ sidebar_position: 6 --- # Micro frontend +Источник: DeepSeek Микрофронтенды (Micro Frontends) — это архитектурный подход, который позволяет разделить фронтенд-приложение на независимые, слабо связанные части, каждая из которых может разрабатываться, тестироваться и развертываться отдельно. Этот подход вдохновлен микросервисной архитектурой и применяется для создания масштабируемых и поддерживаемых фронтенд-приложений. diff --git a/docs/architecture/07-tdd.md b/docs/architecture/07-tdd.md index 56d99b2..e0740e1 100644 --- a/docs/architecture/07-tdd.md +++ b/docs/architecture/07-tdd.md @@ -3,6 +3,7 @@ sidebar_position: 7 --- # Test driven development +Источник: DeepSeek TDD (Test-Driven Development) — это методология разработки программного обеспечения, в которой написание тестов предшествует написанию кода. Основная идея TDD заключается в том, что разработчик сначала пишет тест для новой функциональности, а затем реализует код, который делает этот тест успешным. Этот процесс повторяется для каждой новой функции или улучшения. diff --git a/docs/team/01-methodology.md b/docs/team/01-methodology.md new file mode 100644 index 0000000..a9bda08 --- /dev/null +++ b/docs/team/01-methodology.md @@ -0,0 +1,164 @@ +--- +sidebar_position: 1 +--- + +# Методологии разработки +Источник: DeepSeek + +## Waterfall + +Waterfall (каскадная модель) — это традиционный подход к управлению проектами и разработке программного обеспечения, который предполагает последовательное выполнение этапов. Каждый этап должен быть завершен до перехода к следующему, что делает процесс линейным и предсказуемым. + +Waterfall контрастирует с Agile, где гибкость и итеративность являются ключевыми принципами. + +### Основные принципы Waterfall: +1. Последовательность этапов: + - Проект делится на четкие этапы, которые выполняются один за другим. + - Типичные этапы: сбор требований, проектирование, реализация, тестирование, внедрение и поддержка. +2. Жесткая структура: + - Каждый этап имеет четкие цели и результаты, которые должны быть завершены до перехода к следующему этапу. + - Изменения требований на поздних этапах сложно внедрить. +3. Документирование: + - На каждом этапе создается подробная документация, которая служит основой для следующего этапа. + - Например, требования фиксируются в документе спецификации, который используется для проектирования. +4. Минимум обратной связи: + - Обратная связь от клиента или пользователей обычно происходит только на этапе тестирования или внедрения. + - Это может привести к тому, что продукт не полностью соответствует ожиданиям. +5. Предсказуемость: + - Waterfall подходит для проектов с четкими и неизменными требованиями. + - Бюджет, сроки и ресурсы планируются заранее. + +### Преимущества Waterfall: +- Подходит для проектов с четкими и стабильными требованиями. +- Легко управлять и контролировать процесс. +- Хорошо документированный процесс. + +### Недостатки Waterfall: +- Сложно адаптироваться к изменениям требований. +- Ошибки, обнаруженные на поздних этапах, могут быть дорогостоящими. +- Ограниченная обратная связь с клиентом до завершения проекта. + +### Когда использовать Waterfall: +- Когда требования четко определены и unlikely to change. +- Для небольших проектов с понятной структурой. +- В отраслях с жесткими стандартами (например, строительство, аэрокосмическая промышленность). + +## Agile +Agile (гибкая методология) — это подход к управлению проектами и продуктами, который emphasizes гибкость, итеративность и сотрудничество. Он широко используется в разработке программного обеспечения, но также применяется в других областях. + +Agile помогает командам быстрее реагировать на изменения, улучшать качество продукта и повышать удовлетворенность клиентов. + +### Основные принципы Agile: +1. Итеративность и инкрементальность: Работа делится на небольшие этапы (итерации или спринты), по итогам которых создается работающий продукт или его часть. +2. Гибкость: Возможность быстро адаптироваться к изменениям требований или условий. +3. Сотрудничество: Тесное взаимодействие между командами и заинтересованными сторонами. +4. Фокус на ценности: Приоритет отдается удовлетворению потребностей клиента и доставке ценного продукта. +5. Самоорганизация: Команды самостоятельно принимают решения и распределяют задачи. + +### Популярные фреймворки Agile: +- Scrum: Использует короткие итерации (спринты) и роли (Scrum Master, Product Owner, команда). +- Kanban: Визуализация workflow и ограничение задач в процессе. +- Extreme Programming (XP): Акцент на техническом совершенстве и частых релизах. + +## Scrum +Scrum — это популярный фреймворк Agile, который используется для управления проектами и разработки продуктов. Он основан на итеративном и инкрементальном подходе, где работа делится на короткие циклы (спринты), по итогам которых создается готовый к использованию продукт или его часть. + +Scrum подходит для проектов с изменчивыми требованиями и сложными задачами, где важна быстрая адаптация и постоянное улучшение. + +### Основные принципы Scrum: +1. **Итеративность и инкрементальность:** + - Работа выполняется в коротких итерациях (спринтах), обычно длительностью 1-4 недели. + - В конце каждого спринта команда предоставляет готовый к использованию продукт или его часть. +2. **Самоорганизация команды:** + - Команда самостоятельно распределяет задачи и принимает решения. + - Нет жесткого управления сверху, что способствует ответственности и мотивации. +3. **Прозрачность:** + - Все аспекты работы (задачи, прогресс, проблемы) видимы для всех участников. + - Используются инструменты, такие как Scrum-доска, чтобы визуализировать workflow. +4. **Адаптация:** + - Команда регулярно анализирует результаты и процессы (на ретроспективах) и вносит улучшения. + - Гибкость к изменениям требований и приоритетов. +5. **Фокус на ценности:** + - Приоритет отдается задачам, которые приносят наибольшую ценность для клиента. + - Product Owner отвечает за управление бэклогом продукта и определение приоритетов. + +### Роли в Scrum: +1. **Владелец продукта (Product Owner):** + - Определяет требования и приоритеты задач. + - Управляет бэклогом продукта (списком задач). +2. **Scrum Master:** + - Фасилитатор, который помогает команде следовать принципам Scrum. + - Устраняет препятствия и обеспечивает эффективность процессов. +3. **Команда разработки (Development Team):** + - Самоорганизующаяся группа специалистов, которая выполняет задачи. + - Обычно состоит из 3-9 человек. + +### Артефакты Scrum: +1. **Бэклог продукта (Product Backlog):** + - Список всех задач и требований к продукту. + - Упорядочен по приоритетам. +2. **Бэклог спринта (Sprint Backlog):** + - Список задач, выбранных для выполнения в текущем спринте. +3. **Инкремент продукта (Product Increment):** + - Результат работы за спринт — готовый к использованию продукт или его часть. + +### События Scrum: +1. **Планирование спринта (Sprint Planning):** + - Команда выбирает задачи из бэклога продукта и планирует работу на спринт. +2. **Ежедневный Scrum (Daily Standup):** + - Короткая встреча (15 минут), где каждый участник рассказывает, что сделал, что планирует сделать и какие есть препятствия. +3. **Обзор спринта (Sprint Review):** + - В конце спринта команда демонстрирует результат заинтересованным сторонам. +4. **Ретроспектива спринта (Sprint Retrospective):** + - Команда анализирует процесс и ищет способы улучшить работу в следующем спринте. + +### Преимущества Scrum: +- Гибкость к изменениям. +- Быстрая доставка ценности клиенту. +- Улучшение коммуникации и прозрачности. + +## Kanban +**Kanban** — это метод управления рабочими процессами, который focuses на визуализации задач, ограничении объема работы в процессе (work in progress, WIP) и непрерывном улучшении. Он originated в производственной системе Toyota, но сейчас широко используется в IT, разработке программного обеспечения и других областях. + +Kanban часто сравнивают с Scrum, но в отличие от Scrum, Kanban не требует фиксированных итераций (спринтов) и ролей. Он больше focuses на непрерывном потоке задач и улучшении процессов. + +### Основные принципы Kanban: +1. **Визуализация workflow:** + - Рабочий процесс визуализируется с помощью Kanban-доски, которая разделена на столбцы (этапы работы). + - Каждая задача представляется карточкой, которая перемещается по столбцам по мере выполнения. +2. **Ограничение объема работы в процессе (WIP):** + - Устанавливаются лимиты на количество задач, которые могут находиться на каждом этапе одновременно. + - Это помогает избежать перегрузки команды и улучшает поток задач. +3. **Управление потоком:** + - Фокус на обеспечении плавного и непрерывного движения задач через workflow. + - Анализируются узкие места и устраняются препятствия. +4. **Прозрачность:** + - Все задачи и их статус видны всем участникам команды. + - Это улучшает коммуникацию и понимание текущего состояния работы. +5. **Непрерывное улучшение (Kaizen):** + - Регулярно анализируются процессы и вносятся улучшения. + - Команда стремится к оптимизации workflow и повышению эффективности. + +### Элементы Kanban: +1. **Kanban-доска:** + - Физическая или цифровая доска, разделенная на столбцы (например, "To Do", "In Progress", "Done"). + - Карточки представляют задачи и перемещаются по столбцам. +2. **Карточки (Cards):** + - Каждая карточка представляет одну задачу и содержит информацию о ней (например, описание, приоритет, ответственный). +3. **Лимиты WIP:** + - Устанавливаются ограничения на количество задач, которые могут находиться в каждом столбце одновременно. + - Например, в столбце "In Progress" может быть не более 5 задач. +4. **Поток (Flow):** + - Анализ и оптимизация движения задач через workflow. + - Используются метрики, такие как время выполнения (cycle time) и пропускная способность (throughput). + +### Преимущества Kanban: +- **Гибкость:** Kanban легко адаптируется к изменениям требований и процессов. +- **Прозрачность:** Все задачи и их статус видны всем участникам. +- **Снижение перегрузки:** Лимиты WIP помогают избежать перегрузки команды. +- **Непрерывное улучшение:** Регулярный анализ и оптимизация процессов. + +### Когда использовать Kanban: +- Для проектов с постоянно меняющимися требованиями. +- Для поддержки и улучшения существующих процессов. +- Для команд, которые хотят улучшить прозрачность и управление workflow. \ No newline at end of file diff --git a/docs/team/01-processes.md b/docs/team/01-processes.md deleted file mode 100644 index 6ed576e..0000000 --- a/docs/team/01-processes.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Процессы в команде \ No newline at end of file diff --git a/docs/team/02-methodology.md b/docs/team/02-methodology.md deleted file mode 100644 index a96e8b5..0000000 --- a/docs/team/02-methodology.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Методологии разработки \ No newline at end of file diff --git a/docs/team/02-processes.md b/docs/team/02-processes.md new file mode 100644 index 0000000..b431369 --- /dev/null +++ b/docs/team/02-processes.md @@ -0,0 +1,186 @@ +--- +sidebar_position: 2 +--- + +# Процессы в команде +Источник: https://www.youtube.com/watch?v=zCamBnDSbxs + +01:52 Методологии работы +В канбан-методологии нет четкого планирования на следующий день. +В скрам-методологии спринты имеют определенное планирование. +Спринты автоматизируют процесс разработки, но требуют постоянного планирования. + +02:51 Спринты и их структура +Спринты состоят из десяти рабочих дней, включая выходные. +В спринте делается только одна основная фича. +Обычно идет два спринта параллельно. + +04:39 Этапы разработки +Первый этап: подготовка, где аналитики и дизайнеры работают над ТЗ. +Второй этап: реализация, где команда работает над задачей. +Груминг и планирование обсуждают задачи на следующий спринт и текущий спринт соответственно. + +06:41 Оценка задач и синхронизация +Каждая задача оценивается по времени на планировании. +Важно, чтобы все команды были синхронизированы, чтобы избежать рассинхрона. +Идеальный менеджмент должен учитывать возможные изменения в командах. + +10:04 Введение в синхронизацию команд +Важность синхронизации команд для успешной работы. +Проблемы, возникающие при увольнении члена команды. +Два варианта решения проблемы: уменьшение нагрузки или переработка. + +11:57 Роль менеджера в синхронизации +Менеджер передает задачи от бизнеса команде. +Важность правильного объяснения задач команде. +Влияние менеджера на мотивацию и эффективность команды. + +12:51 Груминг задач +Груминг как процесс выбора задач для работы. +Пример задачи по созданию сторис. +Декомпозиция задачи на более мелкие и выполнимые части. + +15:39 Роль продакт-менеджера +Продакт-менеджер как связующее звено между бизнесом и командой. +Важность поддержки бизнеса и команды. +Влияние продакт-менеджера на процесс принятия решений. + +17:28 Планирование и ретроспективы +Планирование спринтов и ежедневных задач. +Роль менеджера в успокоении бизнеса. +Ретроспективы как отчет о проделанной работе. + +19:17 Заключение +Важность планирования и синхронизации для успешной работы. +Примеры использования инструментов для планирования. +Обзор различных подходов к отображению задач в проекте. + +20:02 Декомпозиция задач и груминг +Аналитики, дизайнеры и бэкендеры проводят груминг, уточняя задачи и подготавливая их для разработчиков. +Цель груминга - расхламление бэклога, удаление неактуальных задач и багов. +Груминг помогает понять, справится ли команда с задачами и уменьшить количество задач в бэклоге. + +21:59 Оценка задач в стори пойнтах +Оценка задач в стори пойнтах помогает понять сложность задачи. +Стори пойнты абстрактны и не всегда точны, но полезны для понимания команды. +Задачи оцениваются по шкале от одного до тринадцати пойнтов, где один пойнт - простая задача, а тринадцать - очень сложная и абстрактная. + +24:52 Проблемы с грумингом и планированием +Если задачи на груминге слишком сложные и абстрактные, это указывает на проблемы с декомпозицией. +На планировании должны быть задачи с оценкой один-пять пойнтов, а большие задачи нужно дробить. +Планирование помогает менеджеру и команде понять, что делать на спринт, и доказать, что все задачи поняты и спланированы. + +28:28 Оценка задач в часах и стори пойнтах +Команды обычно работают в часах, а не в стори пойнтах. +Оценка задач в часах и стори пойнтах одновременно сложна и требует дополнительной абстракции. +Плайн-покер позволяет разработчикам оценивать задачи в часах и стори пойнтах, что помогает экономить время и деньги компании. + +29:27 Проблемы с оценкой задач +Оценка задач может сильно различаться, что требует уточнения. +Если оценки сильно отличаются, это может указывать на разные уровни понимания задачи. +В слабых командах лучше выбирать среднюю оценку, чтобы избежать срывов сроков. + +31:21 Декомпозиция задач и оценка +Декомпозиция задач помогает менеджеру убедиться, что все члены команды понимают ТЗ. +Важно, чтобы вся команда присутствовала на встречах для оценки задач. +Пример из практики: андроид-команда отставала на полгода, что привело к рассогласованию работы. + +32:55 Дейлики и их значение +Дейлики помогают менеджеру понять, что команда делает и планирует на день. +Дейлики включают ответы на три вопроса: что сделано вчера, что будет сделано сегодня, и есть ли блоки. +Дейлики могут быть бесполезными, так как команды работают над разными задачами. + +34:26 Проблемы с дейликами +Дейлики могут быть скучными и бесполезными, так как команды обсуждают разные задачи. +Важно планировать свою речь на дейликах, чтобы не тратить время впустую. +Делики помогают менеджеру понять, что команда работает в одном направлении. + +35:26 Адаптация к делитам +В первые месяцы работы важно активно участвовать в делитах и планировать свою речь. +Делиты могут быть разными в разных командах, и важно адаптироваться к их стилю. +Важно понимать, что делиты могут быть сухими и по фактам, или затягиваться на час, обсуждая детали. + +38:20 Введение в ежедневные встречи +Важно адаптироваться к стилю общения в команде. +Ориентируйтесь на всех членов команды, а не только на менеджера. +Повторяйте структуру и стиль общения команды на ежедневных встречах. + +39:19 Ежедневные ритуалы и их значение +Ежедневные встречи могут длиться от 5 до 40 минут. +Важно мимикрировать под команду и её поведение. +Ежедневные встречи помогают менеджеру понимать текущую ситуацию в команде. + +40:13 Демонстрация и её значение +Демонстрация показывает результаты работы всех отделов. +На демонстрации могут присутствовать представители бизнеса и крупные игроки. +Цель демонстрации — показать бизнесу, что команда выполнила задачи и попросить больше ресурсов. + +41:12 Процесс демонстрации +Демонстрация включает показ работы всех команд продукта. +На демонстрации могут быть голосования и раздачи мерча. +Презентация включает демонстрацию функционала и планы на будущее. + +44:03 Ретроспектива и её значение +Ретроспектива проходит в конце спринта и обсуждает результаты работы. +Демонстрация и ретроспектива помогают бизнесу понять, что команда выполнила задачи. +Важно, чтобы на демонстрации показывался реально рабочий функционал. + +44:44 Демонстрация работы продукта +Демонстрация работы продукта часто скрывает ошибки и недоработки. +Команды могут показывать только часть функционала, чтобы создать иллюзию работы. +Проблемы с бэкендом, тестированием и аналитикой могут привести к задержкам и ошибкам. + +47:25 Ретроспектива и её значение +Ретроспектива помогает выявить проблемы и избежать их в будущем. +Встреча может быть как позитивной, так и негативной, в зависимости от команды и менеджера. +Важно, чтобы вся команда присутствовала и делилась фидбеком. + +48:22 Процесс ретроспективы +Ретроспектива включает обсуждение успехов и неудач спринта. +Команда делится фидбеком анонимно, часто через карточки. +Менеджер зачитывает фидбек и создает тикеты для будущих улучшений. + +49:39 Ретроспектива и планирование +Ретроспектива проводится в конце спринта для подведения итогов. +Груминг может быть в середине недели для планирования. +Компании могут экономить на аналитиках, что негативно сказывается на подготовке к разработке. + +51:50 Релизные циклы +Релизные циклы включают двухнедельный спринт и отправку на ревью. +В понедельник проходят созвоны и планирование, в пятницу подводятся итоги. +Разработка занимает 5-6 дней, остальное время уходит на общение и тестирование. + +54:27 Код-ревью и тестирование +Код-ревью помогает привести код к стандартам компании. +Тестирование проводится после код-ревью для проверки работоспособности. +Тестировщики могут отправлять сборки на тестирование в среду или четверг. + +57:20 Работа с багами +Баги фиксируются в личных сообщениях или тикетах. +Второй вариант с публичными отчетами о багах менее эффективен. +Быстрое решение багов в личных сообщениях экономит время и деньги компании. + +59:14 Решение проблем в личных чатах +Решение проблем в личных чатах или личных сообщениях нормально. +Не обязательно создавать тикеты для каждой мелочи. +Важно, чтобы все работало и соответствовало документации. + +01:00:12 Быстрое выполнение задач +Бизнесу важно быстро выполнить задачу, даже если код не всегда чистый. +Пример с приготовлением салата: можно быстро сделать вкусный салат из доступных ингредиентов. +Важно получить результат, а не стремиться к идеальному качеству. + +01:01:08 Правило Парето +80% усилий приносят 80% результата, и наоборот. +Пример с салатом: можно быстро приготовить вкусный салат, сэкономив время. +Бизнесу важен результат, а не детали. + +01:02:06 Рефакторинг и чистота кода +Рефакторинг существует, несмотря на чистый код. +Не стоит беспокоиться о чистоте кода, главное – соответствие требованиям. +Важно соответствовать запросам бизнеса, а не стремиться к идеалу. + +01:03:05 Срезы и сборки +Срез – это актуальная версия кода для тестировщиков. +Срез может называться по-разному, но суть остается той же. +Важно понимать, что это просто актуальная версия приложения. diff --git a/docs/testing/01-testing.md b/docs/testing/01-testing.md new file mode 100644 index 0000000..0772ef5 --- /dev/null +++ b/docs/testing/01-testing.md @@ -0,0 +1,62 @@ +--- +sidebar_position: 1 +--- + +# Тестирование + +Тестирование фронтенд-приложений — это важный этап разработки, который помогает убедиться, что приложение работает корректно, соответствует требованиям и предоставляет пользователям качественный опыт. Вот основные аспекты и виды тестирования фронтенд-приложений: + +## Виды тестирования фронтенд-приложений +1. Функциональное тестирование + - Проверка, что все функции приложения работают так, как ожидается. Примеры: + - Проверка корректности работы форм, кнопок, ссылок. + - Тестирование взаимодействия с API (например, отправка и получение данных). + - Проверка валидации данных (например, ввод некорректных данных в поля формы). +2. Юзабилити-тестирование + - Оценка удобства использования интерфейса: + - Насколько интуитивно понятен интерфейс. + - Удобство навигации. + - Соответствие ожиданиям пользователей. +3. Кросс-браузерное тестирование + - Проверка корректности отображения и работы приложения в разных браузерах (Chrome, Firefox, Safari, Edge и т.д.) и их версиях. +4. Кросс-платформенное тестирование + - Тестирование на разных устройствах и операционных системах (десктопы, мобильные устройства, планшеты). +5. Тестирование производительности + - Проверка скорости загрузки страниц, отзывчивости интерфейса и работы приложения под нагрузкой. +6. Тестирование доступности (Accessibility) + - Проверка, что приложение доступно для людей с ограниченными возможностями (например, поддержка screen readers, контрастность, управление с клавиатуры). +7. Визуальное тестирование + - Проверка соответствия интерфейса макетам (например, с использованием инструментов вроде Percy или Applitools). +8. Регрессионное тестирование + - Проверка, что новые изменения не сломали существующий функционал. + +Инструменты для тестирования фронтенд-приложений +1. Фреймворки для модульного и интеграционного тестирования + - Jest: популярный фреймворк для unit- и интеграционных тестов. + - Mocha: гибкий фреймворк для тестирования. + - Cypress: инструмент для end-to-end тестирования. + - Puppeteer: библиотека для автоматизации браузера (Chrome/Chromium). +2. Инструменты для кросс-браузерного тестирования + - BrowserStack: облачный сервис для тестирования на разных устройствах и браузерах. + - Sauce Labs: аналогичный сервис для кросс-браузерного тестирования. +3. Инструменты для тестирования производительности + - Lighthouse: встроен в Chrome DevTools, анализирует производительность, доступность и SEO. + - WebPageTest: онлайн-инструмент для анализа скорости загрузки страниц. +4. Инструменты для тестирования доступности + - axe: библиотека для автоматического тестирования доступности. + - WAVE: онлайн-инструмент для проверки доступности веб-страниц. +5. Инструменты для визуального тестирования + - Percy: сервис для визуального тестирования. + - Applitools: инструмент для автоматического сравнения скриншотов. + +## Подходы к тестированию +1. Ручное тестирование + - Тестирование вручную, когда тестировщик проверяет функционал и интерфейс вручную. Полезно для юзабилити-тестирования и exploratory testing. +2. Автоматизированное тестирование + - Написание скриптов для автоматического выполнения тестов. Подходит для регрессионного, функционального и кросс-браузерного тестирования. +3. End-to-End (E2E) тестирование + - Тестирование всего потока приложения от начала до конца (например, от входа пользователя до завершения заказа). +4. Unit-тестирование + - Тестирование отдельных компонентов или функций приложения (например, тестирование отдельной функции JavaScript). +5. Интеграционное тестирование + - Проверка взаимодействия между различными модулями или компонентами приложения. diff --git a/docs/testing/index.md b/docs/testing/index.md deleted file mode 100644 index ef0119d..0000000 --- a/docs/testing/index.md +++ /dev/null @@ -1,3 +0,0 @@ ---- -sidebar_position: 1 ---- \ No newline at end of file