Программа на 24 месяца¶
Формат¶
Программа состоит из четырёх семестров по шесть месяцев. При нагрузке 7–10 часов в неделю один семестр даёт примерно 180–260 часов практики. Время распределяется между чтением, небольшими упражнениями, самостоятельной реализацией, проверкой и разбором ошибок.
Каждый семестр заканчивается работающим проектом. Переход к следующему этапу определяется не датой, а воспроизводимым результатом: другой человек должен суметь запустить проект по README, а автор — объяснить решения и ограничения.
| Семестр | Основная тема | Итоговый результат |
|---|---|---|
| 01 | Программирование и инженерное мышление | Проверяемая консольная программа |
| 02 | Веб-приложение и данные | Развёрнутый сервис с базой данных |
| 03 | Качество и выпуск | Контейнерный сервис с CI и наблюдаемостью |
| 04 | Коммерческий продукт | MVP, пользователи, метрики и первые продажи |
Семестр 01 — основы программирования¶
Цель: уверенно работать с файлами, терминалом, Git и Python; превращать небольшое требование в программу с понятным вводом, выводом и проверками.
План на 26 недель¶
| Недели | Модуль | Проверяемый результат | Статус материалов |
|---|---|---|---|
| 1–2 | 00. Рабочая среда | Запуск Python и безопасная работа с путями | Готово |
| 3–7 | 01. Основы Python | Программа с вводом, условиями, циклами и функциями | Готово |
| 8–10 | 02. Коллекции и строки | Список позиций, поиск и сводная статистика | Готово |
| 11–13 | 03. CSV, JSON и файлы | Импорт и экспорт данных без ручного копирования | Запланировано |
| 14–16 | 04. Ошибки и отладка | Предсказуемые сообщения и журнал диагностики | Запланировано |
| 17–19 | 05. Git и GitHub | Ветка, осмысленный коммит и pull request | Запланировано |
| 20–21 | 06. Автоматические тесты | Не менее пяти проверок ключевой логики | Запланировано |
| 22–23 | 07. Требования и декомпозиция | Сценарии пользователя и план реализации | Запланировано |
| 24–26 | Итоговый проект | Консольный помощник спецификации | Запланировано |
Итоговый проект: пользователь добавляет позиции в небольшой каталог, получает сводку и сохраняет результат в файл. Нейтральный вариант — менеджер домашнего бюджета.
Критерии перехода: проект запускается на чистой системе по инструкции; неверный ввод не уничтожает данные; ключевая логика покрыта автоматическими тестами; автор демонстрирует два обычных и два пограничных сценария и объясняет одну исправленную ошибку.
Семестр 02 — веб-продукт и постоянные данные¶
Цель: создать полезный веб-сервис с интерфейсом, серверной логикой, аутентификацией и базой данных.
Темы: HTML и CSS; доступность; HTTP; формы; Python-веб-фреймворк; SQL; миграции; аутентификация и разграничение доступа; API; тестирование веб-сценариев; базовая защита данных.
Проект: веб-каталог заявок на оборудование с импортом позиций, статусами, поиском, заметками и экспортом. Нейтральный вариант — сервис заявок небольшого клуба.
Критерии перехода: сервис развёрнут в тестовой среде; база создаётся миграциями; секреты не находятся в репозитории; пользовательские данные проверяются на сервере; основные сценарии покрыты тестами.
Семестр 03 — качество, эксплуатация и командная работа¶
Цель: сделать продукт надёжным, наблюдаемым и готовым к регулярным изменениям несколькими разработчиками.
Темы: архитектурные границы; контракты API; расширенное тестирование; Docker; непрерывная интеграция; логирование; метрики; диагностика сбоев; ревью кода; оценка задач; лицензии, приватность и резервное копирование.
Проект: сервис проверки импортированных спецификаций с API, фоновой обработкой и журналом результатов. Нейтральный вариант — валидатор табличных данных.
Критерии перехода: внешний человек поднимает систему по README; сборка и тесты выполняются в CI; сбой можно объяснить по логам; выпуск версии и восстановление данных описаны и повторяемы.
Семестр 04 — коммерческий MVP¶
Цель: выбрать узкий сегмент, подтвердить проблему интервью, выпустить минимальный продукт и измерить реальное использование.
Темы: исследование рынка; интервью без навязывания решения; ценностное предложение; прототипирование; аналитика; ценообразование; платежи и региональные юридические ограничения; поддержка; безопасность; эксплуатация; продажи и демонстрации.
Проект: коммерческий MVP electricity либо независимый продукт. Обязательны лендинг, демонстрационный сценарий, политика обработки данных, канал обратной связи, метрики активации и план продаж.
Финальный критерий: автор самостоятельно проходит полный цикл изменения — формулирует задачу, реализует и тестирует её, выпускает версию, наблюдает результат, разговаривает с пользователем и фиксирует следующий эксперимент.
Правило изменения программы¶
Дорожная карта задаёт результаты, а не жёсткий набор технологий. Фреймворк или сервис можно заменить, если сохраняются проверяемые навыки. Изменение программы записывается в pull request с причиной, влиянием на последующие модули и обновлёнными критериями перехода.