Курсовая по веб-разработке должна показывать работу приложения целиком. Красивый интерфейс без серверной логики является только макетом. REST API без понятного пользовательского сценария тоже не раскрывает прикладную задачу.
Сильный проект показывает путь запроса: пользовательское действие -> frontend -> HTTP -> backend -> база данных -> ответ -> изменение интерфейса.
Определите пользовательский сценарий
Не начинайте с выбора React, Vue или Django.
Сначала ответьте, что пользователь делает.
Например:
- регистрируется;
- ищет товар;
- создаёт заявку;
- оплачивает заказ;
- публикует материал.
Для каждого сценария определите успешный и ошибочный результат.
Страницы и состояния
Экран имеет несколько состояний:
- загрузка;
- успех;
- пустой список;
- ошибка;
- отсутствие доступа.
Не проектируйте только красивое состояние с готовыми данными.
Реальное приложение должно работать и при пустой базе.
Frontend
Разделите интерфейс на компоненты по смыслу.
Не дробите каждую кнопку в отдельный компонент без причины.
И наоборот, не создавайте один компонент страницы на тысячу строк.
Компонентность должна помогать повторному использованию и тестированию.
Состояние
Определите, где хранится:
- локальное состояние формы;
- данные пользователя;
- серверные данные;
- настройки.
Не помещайте всё в глобальное хранилище.
Чем шире область состояния, тем сложнее отслеживать изменения.
Формы
Проверьте:
- обязательные поля;
- формат;
- длину;
- сообщение ошибки.
Но клиентская проверка нужна только для удобства.
Сервер обязан валидировать данные повторно.
Пользователь может отправить запрос напрямую.
HTTP
Понимайте основные методы.
Например:
- GET получает;
- POST создаёт;
- PUT или PATCH изменяет;
- DELETE удаляет.
Не используйте GET для действия, которое меняет данные, только потому, что так проще проверить ссылку в браузере.
Статус-коды
Ответ должен отражать результат.
Например:
- успешный запрос;
- неверный ввод;
- отсутствие авторизации;
- отсутствие права;
- объект не найден;
- серверная ошибка.
Не возвращайте 200 с текстом `error` для любой неудачи.
Клиенту сложнее корректно обработать такой API.
REST API
Для каждого важного endpoint опишите:
- путь;
- метод;
- вход;
- ответ;
- права;
- ошибки.
Не включайте десятки эндпоинтов в отчёт.
Покажите несколько ключевых.
Backend
Бизнес-логика не должна быть размазана по маршрутам.
Разделите:
- HTTP-слой;
- правила;
- доступ к данным.
Так правила можно тестировать отдельно от web-сервера.
База данных
Схема должна соответствовать предметной области.
Определите:
- сущности;
- связи;
- ключи;
- ограничения.
Не храните массив сложных объектов в одном текстовом поле только ради быстрого прототипа, если потом по ним нужно искать.
ORM
Она упрощает типовые операции, но не отменяет понимание SQL.
Проверяйте запросы.
Проблема N+1 может привести к сотням запросов на одну страницу.
Не считайте ORM автоматически оптимальной.
Аутентификация
Определите механизм:
- сессия;
- токен;
- внешний провайдер.
Не храните пароль в открытом виде.
Не включайте реальные токены в отчёт и репозиторий.
Авторизация
Проверяйте права на backend.
Если пользователь не видит кнопку «Удалить», он всё равно может попробовать отправить DELETE-запрос.
Сервер должен отказать.
CSRF и XSS
Если тема проекта требует безопасности, покажите основные угрозы выбранной архитектуры.
Не перечисляйте аббревиатуры без сценария.
Например, XSS становится понятнее через вывод пользовательского HTML без экранирования.
SQL injection
Используйте параметризованные запросы или безопасную ORM.
Не собирайте SQL строкой из пользовательского ввода.
Для курсовой достаточно безопасно описать риск и защиту, не воспроизводя опасные эксплуатационные инструкции.
CORS
Это политика браузера, а не универсальная защита API.
Не считайте, что разрешение только одного origin отменяет необходимость аутентификации и авторизации.
Объясните, какую проблему решает CORS именно в вашем приложении.
Загрузка файлов
Проверьте:
- размер;
- тип;
- имя;
- место хранения;
- права доступа.
Не доверяйте только расширению файла.
Если приложение публичное, загрузка является отдельной поверхностью риска.
Пагинация
Большой список нельзя всегда отдавать целиком.
Используйте:
- limit/offset;
- cursor;
- другую схему.
Покажите, как пользователь переходит по результатам.
Не загружайте 100000 записей в браузер ради простоты.
Поиск
Для маленькой базы `LIKE` может быть достаточно.
Для большой может потребоваться индекс или специальный движок.
Не усложняйте архитектуру до появления требования.
Покажите измерение.
Кэш
Кэш уменьшает нагрузку, но создаёт проблему актуальности.
Определите:
- что кэшируется;
- на сколько;
- когда сбрасывается.
Не кэшируйте пользовательские данные без понимания границ доступа.
Производительность
Разделите:
- время backend;
- время БД;
- сеть;
- frontend.
Медленная страница не всегда означает медленный сервер.
Используйте профилирование или инструменты браузера.
Адаптивность
Проверьте хотя бы основные ширины.
Не просто уменьшайте desktop-дизайн.
На мобильном могут меняться:
- меню;
- таблица;
- форма;
- порядок блоков.
Сценарий должен оставаться выполнимым.
Доступность
Минимально проверьте:
- клавиатуру;
- label;
- контраст;
- focus;
- альтернативный текст.
Не делайте интерфейс, который работает только мышью.
SEO
Если проект публичный и контентный, учитывайте:
- доступность страницы роботу;
- title;
- description;
- структурированную разметку, если уместно;
- скорость.
Но для закрытой внутренней системы SEO может вообще не быть требованием.
Логи
Backend должен фиксировать ошибки и ключевые события.
Не логируйте пароль, cookie или токен.
Для диагностики достаточно контекста без секретов.
Тестирование
Минимально полезны:
- unit-тест бизнес-правила;
- integration-тест API и БД;
- один сквозной сценарий.
Не проверяйте всё только вручную через браузер.
Развёртывание
Опишите среду:
- приложение;
- БД;
- переменные окружения;
- HTTPS;
- домен, если нужен.
Не храните конфигурацию production прямо в исходном коде.
Защита
Покажите один сценарий от клика до записи в БД.
Затем покажите ошибочный сценарий и тест.
Курсовая по веб-разработке выглядит профессионально тогда, когда frontend и backend образуют одну систему, а интерфейс, данные, безопасность и тестирование связаны с реальными действиями пользователя.
Степан Сергеев
Кандидат физико-математических наук, PhD. Лично разбираю требования, веду работу по этапам и остаюсь на связи до защиты.