4 МИН
Сегодня поговорим про процесс разработки программного обеспечения. Обычно процесс разбивается на следующие фазы:
Сбор требований с точки зрения бизнеса желательно без технических деталей ведь пользователям важен конечный продукт а не технические детали.
Проработки архитектуры важный шаг, актуальный если приложение начинают писать с нуля или текущая архитектура не позволяет реализовать существующие требования. На данном этапе важно понять: какие требования по надежности, скорости работы, простоте и дешевизне в поддержке инфраструктуры, а так же масштабируемости. Далее на базе этого разработать техническое решение, определиться с используемыми технологиями. Будет ли это микросервис или монолит, как будем и где разворачивать в контейнеры или на виртуальные машины, если есть требование обновлять функционал без прекращения обслуживания, если есть то надо это учитывать как в инфраструктуре, так и в процессе разработки (понимать что одновременно может работать как новая так и старая версии приложения, при этом использовать они будут одну и ту же базу данных, а значит, если для новой версии надо менять структуру базы, то так, чтоб не ломалась предыдущая версия), предусмотреть возможность отката хотя бы на одну версию назад если при выкатке новой что-то пойдет не так.
Разработка функционала начинается с разбивки бизнес требований на более мелкие конкретные технические задачи, которые можно выполнять параллельно несколькими разработчиками, часто включает написание юнит и интеграционных тестов, ревью кода другими разработчиками, функционал можно тестировать, когда написан минимальный и достаточный код, автоматические проверки выполнены успешно.
Развертывание на тестовом окружении вручную или автоматически.
Тестирование и исправление критических ошибок (возможно несколько циклов пока не будет достигнуто требуемое качество с точки зрения бизнеса).
Развертывание на стейджинге когда все критические ошибки были исправлены можно развернуть на стейджинг окружении на котором произвести демонстрацию для клиента/заказчика.
Развертывание в продакшене в этот момент приложение становится доступным для реальных пользователей.
И далее, если есть запрос на новый функционал, все начинается сначала.
Важный показатель процесса - время, прошедшее от запроса нового функционала до того момента, когда он появился в доступе для конечного пользователя (time to market).
Бывает так что чем быстрее, тем лучше, чтобы опередить конкурентов и удержать клиентов.
Для этого процесс надо выстраивать так чтоб можно было не копить функционал а выпускать поштучно по мере готовности. На тестирование больше нагрузка и того дороже, есть смысл покрыть авто тестами.
Спасибо, что заглянули,
добавляйтесь в
Telegram
канал и будьте в курсе новинок.
Если Вам было интересно, можете поддержать автора