Как строится современное веб-приложение
Результат анализа нескольких десятков проектов, в которых были созданы программные продуктов в виде веб-приложений
Я изложил его в виде списка задач, которые возникают на этапах от проектирования до коммерческой эксплуатации современных веб-приложений.
Список основан на реальных задачах, извлечённых из систем управления задачами, проектами, систем отслеживания ошибок, (Issue & Bug Tracking Software, Project Management Software) таких как Jira, Redmine, Microsoft Project.
Мне встречались задачи разного масштаба: и тысячи мелких багов и глобальные «захватить мир».
Список не стоит рассматривать как набор действий. В проектах разного уровня сложности они могут быть, а могут отсутствовать, могут выполняются в разном порядке. Некоторые задачи могут повторяться многократно по мере роста сложности. Некоторые могут быть не решены никогда, хотя очень хочется сделать их и забыть навсегда.
Как рождается веб-приложение? Это делается постепенно, шаг за шагом, в систему вводятся новые и новые части, между которыми появляется всё больше и больше связей.
Итак, с чего всё начинается? С идеи.
- анализ предметной области
- принятие решения о необходимости программной реализации бизнес-процессов — всех или какой-то их части
- выделение ролей пользователей, то есть групп пользователей, которые будут пользоваться программным продуктом, с разными задачами и полномочиями (например, посетители интернет-магазина, покупатели, сотрудники службы поддержки, сотрудники службы доставки, маркетологи)
- определение функций, операций или ролевых задач, то есть списков действий пользователей, которые они должны выполнять с использованием программного продукта
- определение данных, которыми пользователи должны оперировать
На основе анализа строится предположение, как могло бы выглядеть программное решение
- проектирование интерфейса пользователя
- описание процессов взаимодействия пользователей с программным продуктом (use-case)
Возможно, в компании уже есть какое-то частичное программное решение для отдельных бизнес-процессов
- анализ имеющихся программных решений
- описание процессов взаимодействия существующих программных решений с проектируемым
- описание форматов данных для обмена
- описание регламента обмена данными
Возможно, старое программное решение должно быть заменено новым
- описание модели данных старого приложения
- описание логики старого приложения
- описание
Далее вступают в дело архитекторы программных продуктов
- составление или уточнение модели данных — что будем хранить
- выбор СУБД для хранения модели — где будем хранить
- выбор языка программирования
- выбор архитектуры приложения
- составление объектной модели приложения
Регулярно требуется выполнить прогноз сроков решения задач
- составление RoadMap — укрупнённого списка задач на далёкую перспективу
- выделение приоритетных задач
- декомпозиция задач — разбиение на мелкие подзадачи, которые могут быть достаточно чётко описаны и имеют короткий срок реализации
Наконец дело дошло до разработчиков
- репозиторий кода
- реализация программного каркаса приложения, реализация доступа к данным в базе — обычно на базе какого-нибудь фреймворка, но бывает и без него
- вёрстка интерфейса пользователя
- реализация модели данных в СУБД и проекции на объектную модель
- реализация авторизации пользователей
- реализация регистрации пользователей по инвайтам — это бывает нужно на начальном этапе, чтобы неудачные архитектурные решения не приводили к отказам при нагрузке
- разделение пользователей по правам
- система управления контентом — под контентом подразумевается не только статьи в блоге, но и вообще всё, что пользователь может видеть и изменять
- панель администратора для управления пользователями и контентом
- параметризованный и полнотекстовый поиск контента
- реализация API для внешних сервисов, например для выдачи в другое приложение в той же организации или обмен данными с мобильными версиями приложений
- агрегация данных из внешних источников
- миграция данных их старых приложений — см выше где «возможно, старое программное решение должно быть заменено»
- юнит-тесты или модульные тесты
- непрерывная интеграция
Админы стоят на подмоге
- управление доменными именами
- управление хостингом
- доступ к серверам
- бакапы баз данных
- бакапы пользовательских данных — картинки, документы и прочее
- установка новых версий приложений на сервер приложений — хотя бы вручную
- автоматизированное обновление сервера приложений — а вот это уже не вручную
- автоматическая миграция данных при обновлениях
- откат обновлений — если в последней версии обнаружили неустранимую ошибку
- распределённый обмен данными — хотя бы через Dropbox
Тестировщики проверяют соответствие решений и исходных требований, помогают улучшать интерфейсы и заботятся о безопасности
Маркетологи хотят много аналитических данных и захватить мир
- трекинг действий пользователя
- статистика по продажам
- складской учёт
- подписка пользователей на почтовые рассылки
- уведомления пользователей об изменениях в системе
- и другие массовые рассылки сообщений
Служба поддержки хочет иметь возможность более тесно взаимодействовать с пользователями системы
- организация обратной связи из приложения через веб-сайт
- … и через почту
- … и через телефон
- … с авто-ответчиком
- … и регистрацией всех обращений в базе данных (CRM)
- … а ошибок — в системе отслеживания ошибок
- работа с почтовыми службами, например, дублирование переписки с пользователям через веб-сайт и через электронную почту
Вопросы безопасности и стабильности когда-нибудь выходят на первый план
- защита от взлома — ограничение на количество попыток входа, блокировка по IP, более строгие проверки
- защита от роботов, которые пытаются выдать себя за реальных пользователей, а на самом деле ищут способы внедрить спам и вирусы
- защита файлов от изменений (системные утилиты)
- автоматическое восстановление из бакапов
Количество пользователей растёт и пора оптимизировать её работу
- оптимизация запросов в СУБД
- кэширование данных
- инвалидация данных в кэше
- щадящая, выборочная инвалидация данных
- сквозное кэширование
- прогревка кэша
- поиск неоптимальных программных алгоритмов
- реализация долгих операций в асинхронном режиме, по расписанию или через постоянные демоны, а также через очереди
В системе начинают проявляться проблемы роста нагрузки, пришла пора highload
(возвращаемся к этапу выбора архитектуры, если текущая версия не позволяет увеличить производительность)
- разделение данных на несколько баз данных, горизонтальное масштабирование
- разделение данных на несколько баз данных, вертикальное масштабирование
- зеркалирование данных (readonly + read/write)
- миграция данных с учётом масштабирования баз данных
- мониторинг характеристик серверов в режиме реального времени
- уведомления о сбоях серверов
- оперативная замена основного сервера базы данных зеркалом + режим readonly
- автоматическая замена серверов при сбоях
- балансировка нагрузки сервера приложений
- автоматизированное обновление нескольких серверов при балансировке нагрузки
- автоматическое введение новых узлов сети (при использовании облаков)
- отдельный сервер для пользовательского медиаконтента — фотографий, видео, музыки
- несколько серверов для пользовательского медиаконтента
Админы заметили, что сервера используются неоптимально
- регулярная автоматическая чистка места на дисках
База пользователей стала большой
- массовые рассылки электронных сообщений
На сайте нужен приём платежей
- интеграция с платёжными системами
Пользователи хотят мгновенных уведомлений о разных событиях
- интеграция с SMS шлюзами
- интеграция с системами сообщений через социальные сети
- интеграция с сервисами сообщений типа Telegram
Маркетологи считают, что внутренняя реализация работы с пользователями недостаточно гибкая
- интерация с системами CRM
- интерация с системами сбора аналитических сведений
Остались за кадром, но тоже требуются
- создание настольной (desktop, standalone) версии приложения
- создание мобильного приложения
- интеграция с социальными сетями, например приложения для vKontakte
- SEO-оптимизация
Что я забыл? Вписывай в комментарии.
