Полный цикл разработки

Полный цикл разработки (End-to-End Development) - подход, при котором продукт проходит все основные этапы SDLC: от анализа требований и проектирования до разработки, тестирования, запуска, эксплуатации и дальнейшего развития.

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

Типовой жизненный цикл выглядит так:

Идея
 ↓
Анализ
 ↓
Проектирование
 ↓
UX/UI
 ↓
Разработка
 ↓
Тестирование
 ↓
Релиз
 ↓
Эксплуатация
 ↓
Развитие

Анализ требований

Разработка начинается с определения задачи, которую должна решать система.

На этом этапе фиксируются:

• Бизнес-цели проекта.
• Пользовательские сценарии.
• Функциональные требования.
• Нефункциональные требования.
• Ограничения.
• Интеграции.
• Требования к безопасности.
• Требования к производительности.
• Критерии приемки.

Функциональные и нефункциональные требования

Функциональные требования

Описывают, что система должна уметь делать.

Например:

• Пользователь может зарегистрироваться.
• Менеджер может изменить статус заказа.
• Система передает заказ в CRM.
• Администратор может управлять ролями.

Нефункциональные требования

Определяют характеристики системы.

Например:

• Допустимое время ответа.
• Ожидаемую нагрузку.
• Требуемую доступность.
• Требования безопасности.
• Масштабируемость.
• Требования к резервному копированию.
• Требования к совместимости.

Пользовательские сценарии

Требования полезно описывать через реальные действия пользователей.

Например:

Пользователь открывает каталог
 ↓
Выбирает товар
 ↓
Добавляет его в корзину
 ↓
Оформляет заказ
 ↓
Оплачивает
 ↓
Получает подтверждение

Такая последовательность помогает определить, какие компоненты, данные и интеграции необходимы для реализации сценария.

Критерии приемки

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

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

Например:

Пользователь может восстановить пароль,
если email зарегистрирован в системе.

После отправки формы:
- Создается одноразовый token.
- Пользователь получает письмо.
- Token имеет ограниченный срок действия.
- После смены пароля token становится недействительным.

Оценка проекта

До начала активной разработки оцениваются основные ограничения проекта.

• Объем функциональности.
• Количество интеграций.
• Сложность предметной области.
• Требования к инфраструктуре.
• Состав команды.
• Риски.
• Сроки.
• Бюджет.

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

Проектирование архитектуры

Архитектура определяет основные компоненты системы и правила их взаимодействия.

На этом этапе рассматриваются:

• Границы модулей.
• Модель данных.
• API.
• Интеграции.
• Аутентификация и авторизация.
• Кеширование.
• Очереди.
• Отказоустойчивость.
• Масштабирование.

Упрощенная схема веб-системы может выглядеть так:

Client
  ↓
Frontend
  ↓
API
  ↓
Backend
  ├── Database
  ├── Cache
  ├── Queue
  └── External Services

Выбор технологического стека

Технологии выбираются после понимания требований проекта.

При выборе учитываются:

• Тип продукта.
• Сложность бизнес-логики.
• Ожидаемая нагрузка.
• Требования к SEO.
• Необходимые интеграции.
• Компетенции команды.
• Стоимость эксплуатации.
• Срок жизни системы.

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

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

Проектирование данных

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

Например:

User
 ↓
Order
 ↓
Order Item
 ↓
Product

При проектировании учитываются:

• Связи между сущностями.
• Ограничения целостности.
• Транзакции.
• Индексы.
• История изменений.
• Объем данных.
• Частота чтения и записи.

API-контракты

Если frontend, мобильное приложение или внешние системы взаимодействуют с backend через API, желательно заранее определить основные контракты.

Контракт описывает:

• Endpoint.
• HTTP-метод.
• Структуру запроса.
• Структуру ответа.
• Ошибки.
• Авторизацию.

Для HTTP API часто используется спецификация OpenAPI.

UX и прототипирование

До реализации интерфейса полезно определить структуру пользовательских сценариев.

Прототип помогает проверить:

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

UI-дизайн

После определения пользовательской логики формируется визуальная система интерфейса.

Она может включать:

• Типографику.
• Цветовую систему.
• Сетки.
• Компоненты.
• Состояния элементов.
• Адаптивное поведение.

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

Разработка

После проектирования начинается реализация системы.

Разработка может включать:

• Frontend.
• Backend.
• Базу данных.
• API.
• Интеграции.
• Фоновые задачи.
• Административные интерфейсы.
• Инфраструктурный код.

Декомпозиция задач

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

Например:

Оформление заказа
├── Корзина
├── Форма контактов
├── Расчет доставки
├── Создание заказа
├── Оплата
└── Уведомление

Такая декомпозиция упрощает оценку, разработку, тестирование и контроль прогресса.

Работа с исходным кодом

Для управления изменениями используется система контроля версий.

Git позволяет:

• Хранить историю изменений.
• Разрабатывать функции независимо.
• Выполнять Code Review.
• Возвращаться к предыдущим версиям.
• Связывать изменения с задачами и релизами.

Code Review

Перед объединением изменений код может проходить проверку другим разработчиком.

При Code Review оцениваются:

• Корректность реализации.
• Читаемость.
• Архитектурные границы.
• Безопасность.
• Обработка ошибок.
• Покрытие тестами.

Статический анализ

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

Для этого используются:

• Linters.
• Type Checkers.
• Static Analyzers.
• Dependency Scanners.
• Security Scanners.

Тестирование

Разные классы ошибок требуют разных уровней тестирования.

Типовая пирамида:

       E2E
    Integration
      Unit

Unit-тестирование

Проверяет небольшие изолированные части бизнес-логики.

Integration-тестирование

Проверяет взаимодействие компонентов между собой и с инфраструктурой.

Например:

• Backend и база данных.
• Сервис и брокер сообщений.
• API и внешний сервис.

End-to-End тестирование

Проверяет полный пользовательский сценарий.

Например:

Вход
 ↓
Добавление товара
 ↓
Оформление заказа
 ↓
Оплата
 ↓
Подтверждение

Ручное тестирование

Не каждый сценарий экономически оправданно автоматизировать.

Ручное тестирование может использоваться для:

• Проверки нового интерфейса.
• Исследовательского тестирования.
• Проверки редких сценариев.
• Визуальной проверки.
• Приемочного тестирования.

Регрессионное тестирование

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

Для этого используется regression suite или набор контрольных сценариев.

В первую очередь проверяются критические функции:

• Авторизация.
• Платежи.
• Заказы.
• Пользовательские права.
• Интеграции.

UAT

User Acceptance Testing - приемочное тестирование с точки зрения бизнес-требований и пользовательских сценариев.

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

Тестирование производительности

Для систем с требованиями к нагрузке могут выполняться специальные проверки.

Используются:

• Load Testing.
• Stress Testing.
• Soak Testing.

При анализе проверяются:

• Latency.
• Throughput.
• Error Rate.
• CPU.
• Memory.
• Database Load.

Безопасность в цикле разработки

Безопасность желательно учитывать не только перед production-релизом.

Secure SDLC может включать:

Requirements
   ↓
Threat Modeling
   ↓
Development
   ↓
Code Review
   ↓
Security Testing
   ↓
Deployment
   ↓
Monitoring

На разных этапах проверяются:

• Права доступа.
• Валидация данных.
• Секреты.
• Зависимости.
• Конфигурация инфраструктуры.
• Известные классы уязвимостей.

Окружения

Разработка обычно выполняется не непосредственно на production.

Могут использоваться:

• Local.
• Development.
• Test.
• Staging.
• Production.

Количество окружений зависит от размера и требований проекта.

CI/CD

Continuous Integration и Continuous Delivery позволяют автоматизировать проверку и доставку изменений.

Типовой pipeline:

Commit
 ↓
Build
 ↓
Static Analysis
 ↓
Tests
 ↓
Package
 ↓
Deploy
 ↓
Verification

Автоматизация снижает количество ручных операций и делает процесс выпуска более воспроизводимым.

Deployment

Процесс развертывания зависит от архитектуры системы.

Могут использоваться:

• Обычный deployment.
• Rolling Deployment.
• Blue-Green Deployment.
• Canary Deployment.

Миграции базы данных

Изменения приложения часто сопровождаются изменением структуры данных.

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

Для сложных изменений может использоваться постепенная схема:

Добавить новую структуру
 ↓
Развернуть совместимый код
 ↓
Перенести данные
 ↓
Переключить использование
 ↓
Удалить старую структуру

План отката

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

Rollback может затрагивать:

• Код приложения.
• Container Image.
• Конфигурацию.
• Feature Flags.
• Изменения базы данных.

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

Feature Flags

Feature Flags позволяют развернуть код новой функции, но управлять ее включением отдельно.

Это может использоваться для:

• Постепенного запуска.
• Ограниченного тестирования.
• Быстрого отключения функции.
• A/B Testing.

Мониторинг после релиза

Успешный deployment не означает, что релиз завершен.

После запуска проверяются:

• Error Rate.
• Latency.
• CPU и Memory.
• Состояние баз данных.
• Очереди.
• Внешние интеграции.
• Критические бизнес-метрики.

Наблюдаемость

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

Observability обычно включает:

• Логи.
• Метрики.
• Трассировки.

Например:

User Request
     ↓
Frontend
     ↓
API
     ↓
Service
     ↓
Database
     ↓
External API

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

Алерты

Мониторинг становится полезнее, если значимые отклонения автоматически приводят к уведомлению.

Алерты могут срабатывать при:

• Росте Error Rate.
• Увеличении Latency.
• Недоступности сервиса.
• Нехватке ресурсов.
• Росте Queue Lag.
• Ошибках критической интеграции.

Сопровождение

После запуска система продолжает изменяться.

Эксплуатация включает:

• Исправление ошибок.
• Обновление зависимостей.
• Обновление инфраструктуры.
• Мониторинг.
• Резервное копирование.
• Реагирование на инциденты.
• Оптимизацию производительности.

Развитие продукта

После первого релиза появляются новые данные о поведении пользователей и реальной работе системы.

Это может приводить к:

• Изменению пользовательских сценариев.
• Добавлению новых функций.
• Удалению невостребованных возможностей.
• Оптимизации производительности.
• Изменению архитектуры.

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

Анализ
 ↓
Разработка
 ↓
Релиз
 ↓
Измерение
 ↓
Обратная связь
 ↓
Новый анализ

Технический долг

Во время разработки часть решений принимается с учетом текущих сроков и ограничений.

Со временем это может создавать технический долг.

Он может проявляться как:

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

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

Рефакторинг

Рефакторинг изменяет внутреннюю структуру кода без изменения его внешнего поведения.

Он может использоваться для:

• Упрощения архитектуры.
• Устранения дублирования.
• Повышения тестируемости.
• Подготовки системы к новой функциональности.

Документация

Документация помогает сохранить знания о системе при развитии проекта и изменении состава команды.

В зависимости от проекта документируются:

• Архитектура.
• API.
• Модель данных.
• Deployment.
• Интеграции.
• Процедуры восстановления.
• Критические бизнес-процессы.

Architecture Decision Records

ADR используются для фиксации значимых архитектурных решений.

Обычно документ отвечает на вопросы:

• Какую проблему решали.
• Какие варианты рассматривали.
• Какое решение выбрали.
• Какие компромиссы приняли.

Это помогает спустя время понять причины существующей архитектуры.

Методологии управления разработкой

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

Подход выбирается в зависимости от характера требований и организационных ограничений.

Agile

Agile объединяет принципы итеративной разработки и регулярной обратной связи.

Для проекта это может означать:

• Короткие итерации.
• Регулярные демонстрации.
• Пересмотр приоритетов.
• Постепенный выпуск функциональности.

Scrum

Scrum - один из frameworks для организации итеративной работы.

Обычно используются:

• Product Backlog.
• Sprint.
• Sprint Planning.
• Daily Scrum.
• Review.
• Retrospective.

Kanban

Kanban ориентирован на управление потоком работы и ограничение количества одновременно выполняемых задач.

Типовая доска:

Backlog
   ↓
In Progress
   ↓
Review
   ↓
Testing
   ↓
Done

Waterfall

Waterfall предполагает более последовательное прохождение этапов.

Такой подход может применяться там, где:

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

Гибридный подход

На практике проекты часто комбинируют несколько методов.

Например:

Фиксированная архитектурная фаза
        ↓
Итеративная разработка
        ↓
Формальное приемочное тестирование
        ↓
Регламентированный релиз

Управление изменениями требований

Требования могут изменяться во время разработки.

Важно определить процесс:

Новое требование
      ↓
Анализ влияния
      ↓
Оценка
      ↓
Приоритизация
      ↓
Изменение backlog / scope

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

Управление рисками

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

Например:

• Изменение требований.
• Недоступность внешнего API.
• Нехватка производительности.
• Сложная миграция данных.
• Уязвимости.
• Зависимость от одного поставщика.
• Недостаток документации.

Контроль сроков

Для управления сроками задачи декомпозируются, оцениваются и связываются с зависимостями.

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

Definition of Done

Для команды полезно определить общие требования к завершенной задаче.

Например:

• Код реализован.
• Code Review пройден.
• Тесты добавлены.
• Документация обновлена.
• Изменение проверено на test-окружении.
• Критерии приемки выполнены.

Полный цикл не означает строго линейный процесс

Этапы разработки не всегда проходят один раз и в строгой последовательности.

Например, результаты тестирования могут привести к изменению архитектуры, а обратная связь пользователей - к пересмотру требований.

Поэтому реальный процесс чаще выглядит так:

Анализ
 ↓
Проектирование
 ↓
Разработка
 ↓
Тестирование
 ↓
Обратная связь
 ↖───────────────┘

Основная задача полного цикла

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

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

Поэтому SDLC охватывает весь путь изменения:

Требование
 ↓
Решение
 ↓
Код
 ↓
Проверка
 ↓
Production
 ↓
Мониторинг
 ↓
Обратная связь
 ↓
Следующее изменение