Передача проекта другому разработчику

Передача проекта начинается не с архива «всё вместе», а с объяснения того, какие файлы являются исходниками и какое поведение они должны давать. Другому разработчику нужно понимать входные данные, адреса, подготовленные сценарии и действия, которые ещё не выполнялись. Без этого даже маленькая лаборатория превращается в набор догадок.

В lesson-23 архива подготовлен завершённый вариант нашего локального каталога. Документ handover.md хранится рядом с ним как материал передачи. Программы, сервер, проверки и публикация не выполнялись. Поэтому описание прямо разделяет подготовленные источники и ожидаемые результаты.

Что находится в проекте

У лаборатории четыре исходника: server.py, public/index.html, public/theme.css и public/app.js. Python отвечает за маршруты и вымышленные данные, HTML содержит начальный список, CSS задаёт оформление, JavaScript загружает выбранную тему и считает длительность видимых карточек.

Такое описание связывает файл с обязанностью. Запись «в папке лежит Python и фронтенд» гораздо менее полезна: она не объясняет, где искать ошибку запроса, начальный DOM или конфликт цвета. Новый автор должен быстро сопоставить задачу с конкретным местом, а затем читать сам исходник.

Для лаборатории нужен Python 3.12 или новее и современный Chrome/Chromium. Внешние пакеты и сборочный инструмент не используются. Версия указана как условие подготовленного примера, а не как утверждение о проверенном запуске на каждом доступном компьютере. Документация http.server описывает стандартные HTTP-классы; наш обработчик предназначен только для отдельного локального упражнения.

Передаваемые файлы не содержат .git, node_modules, настоящих токенов или состояния профиля браузера. Историю Git сценариев получатель при желании создаёт отдельно по инструкциям. Ожидаемые снимки не являются сохранённой исполнявшейся историей и не имеют подлинных хешей учебных коммитов.

Запуск как отдельное действие

В документе передачи запишите адрес http://127.0.0.1:4310/ и команду будущего ручного запуска python3 server.py из папки лаборатории. Сначала получатель проверяет назначение папки и отсутствие другого процесса на выбранном порту. Сервер привязан только к 127.0.0.1; публикация в сеть не является частью упражнения.

Важно не скрывать рабочий каталог за командой. Если запустить другую копию server.py или открыть страницу на порту предпросмотра ProfessorWeb, наблюдение будет относиться к другому набору данных. Поэтому передача должна связывать три вещи: выбранный снимок файлов, папку запуска и адрес браузера.

В текущем документе состояние запуска — not_run. Получатель может выполнить его позднее в разрешённом окружении и добавить собственное наблюдение. Это не уменьшает полезность подготовленного материала: честная граница позволяет планировать дальнейшую работу и не принимать неподтверждённый результат за основание выпуска.

После будущей ручной работы сервер останавливается в том же терминале. Точки останова, Offline и другие сетевые ограничения в DevTools снимаются. Локальные учебные записи хранилищ очищаются по точным именам. Эти действия возвращают окружение в понятное состояние и не относятся к очистке данных других сайтов.

Данные и постоянные маршруты

На сервере задано два курса. JavaScript имеет 60 минут, HTML/CSS — 48; оба относятся к frontend. Идентификаторы, названия и постоянные URL следует сохранить при передаче. Тема publishing допустима, но её список пустой. Значение fronted ошибочно и должно дать 400.

Запрос	Ожидаемое содержание
/api/courses?topic=all	Два курса
/api/courses?topic=frontend	Те же два курса
/api/courses?topic=publishing	Пустой массив
/api/courses?topic=fronted	Problem JSON, статус 400

Это таблица договора, а не записанные ответы сервера. По тому же принципу в проекте ProfessorWeb полезно хранить договор о прежних входных URL отдельно от текущей красоты каталога. Другая команда должна знать, какие адреса нельзя переименовать просто ради нового названия раздела.

Начальные карточки встроены в HTML. Сохранённая тема меняет пункт формы, но загрузка API начинается только после нажатия кнопки. Общая длительность считается по текущим карточкам DOM. Эти две детали описывают поведение, которое легко неправильно понять, если передать только список файлов.

Известные состояния браузера

LocalStorage содержит только несекретный catalog-topic. Cookie lab_view=cards устанавливается при GET главной страницы и не используется для доступа. Cache Storage приложение не читает; демонстрационный catalog-lab-demo создавался бы только вручную для урока. Service Worker отсутствует.

HTTP-кеш CSS допускается на 120 секунд, а API, HTML и JavaScript имеют no-store. В документе это условие важно для будущего исследования обновления оформления. При этом нельзя обещать конкретную колонку кеша или время загрузки без наблюдения браузера: они зависят от состояния окружения.

Также зафиксируйте, что ошибок авторизации здесь нет, потому что сама авторизация не реализована. Учебный cookie не является безопасной моделью производственной сессии. В передаче лучше прямо написать границу, чем заставить нового автора догадываться, какие отсутствующие функции намеренны, а какие случайно потеряны.

История решений и дальнейшая задача

Полезно перечислить три уже подготовленные правки: убрать специфичное фиолетовое правило карточки, преобразовать длительности в числа, сохранить правильное значение frontend при запросе. Они связывают завершённые исходники с предыдущими сценариями. Получатель сможет вернуться к начальному варианту нужного урока и понять механизм ошибки.

Отдельно запишите возможное дальнейшее улучшение: понятное сообщение для пустого результата темы «Публикация». Это ещё не реализация и не критерий готовности нынешнего варианта. Важно не смешивать известные ограничения, будущие идеи и фактически внесённые изменения одним списком «сделано».

Передача также должна обозначать ответственность за следующую операцию. Кто выбирает новую задачу, кто читает изменение и кто разрешает выпуск? В учебной модели эти роли описываются без действительных имён и аккаунтов. Для настоящего проекта договор команды важнее того, насколько подробна команда запуска в README.

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

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