Пет-проекты
Идеи проектов по уровню сложности — План развития разработчика.
Процесс от задачи до сдачи — Процесс разработки ПО.
Git и публикация — Как работать с Git, шпаргалка сценариев с разбором, кейс GitHub Pages.
Структура репозитория — README, Организация кодовой базы.
Пет-проект
Что такое пет-проект?
Пет-проект (от pet project) — программный проект, инициированный и реализуемый разработчиком в личное время, без внешнего заказа, коммерческого контракта или корпоративного ТЗ. Цель проекта определяется инициатором автономно.
Пет-проект (от английского pet — "питомец") — это дело, которое вы делаете для души в свободное время, а не по работе или учебе.
Примеры пет-проектов из жизни обычных людей:
- Программист пишет бота для Telegram, который присылает цитаты из любимого фильма.
- Дизайнер рисует вымышленные постеры для несуществующего кинофестиваля.
- Копирайтер ведёт канал в Telegram про свою кошку — просто потому что смешно.
- Школьник собирает на коленке сайт с рецептами своих печенек.
- Бухгалтер создаёт табличку в Excel, чтобы считать, сколько денег уходит на кофе в год (и как сэкономить).
Зачем люди этим занимаются?
-
Для души — чтобы отдохнуть от скучной работы и вспомнить, почему вообще любишь своё дело.
Без KPI и чужого ТЗ можно экспериментировать с идеей, которая на работе "не в приоритете".
-
Научиться новому — например, попробовать другой язык программирования или новый стиль в дизайне без риска напортачить на работе.
Ошибка в пет-проекте не ломает прод заказчика; зато появляется repo с примерами для собеседования.
-
Показать другим — положить в портфолио. Работодатели любят, когда человек сам горит идеей, а не только таски по Jira закрывает.
Живой GitHub с коммитами убедительнее строки "знаю React" в резюме без ссылок.
-
Просто победить скуку — вместо сериала на диване.
Даже "мелочь" вроде бота с мемами тренирует привычку доводить до рабочего состояния.
Пет-проект может потом превратиться в бизнес или принести деньги. Но изначально его смысл — не заработать. Если вы с первого дня думаете "как монетизировать", то это уже стартап или подработка.
Например, Вселенная IT — мой пет-проект: флагманский и крупный, но изначально он тоже начинался как "дело для души" и эксперимент с подачей материала.
Ключевые признаки
-
Отсутствие формального SOW (Statement of Work), SLA, KPI.
Нет договора "сдать к пятнице с метрикой uptime 99,9 %". Вы сами решаете, когда достаточно хорошо для MVP; сроки гибкие, но и ответственность только перед собой.
-
Собственническое право на кодовую базу и артефакты.
Код на работе часто принадлежит компании. В пет-проекте вы владеете репозиторием (если не скопировали чужой проприетарный код) и выбираете лицензию — MIT, Apache и т.д.
-
Гибкий жизненный цикл — может быть завершён, заморожен, перепроектирован или открыт как OSS.
Проект можно закрыть без "штрафа", переписать на другом стеке или выложить открыто — без согласования с IT-отделом.
-
Технологический выбор не ограничен корпоративными стандартами.
Хотите Rust вместо принятого в компании Java — можно. Ограничение одно: ваше время и цель обучения, а не корпоративный каталог разрешённых библиотек.
Классификация по мотивации
| Тип | Цель | Примеры |
|---|---|---|
| Обучающий | Освоение новой технологии, парадигмы, инструмента | Реализация HTTP-сервера на сокетах; SPA на Svelte; CLI-утилита на Rust |
| Демонстрационный | Формирование портфолио, подтверждение компетенций | Full-stack блог с аутентификацией, CI/CD, мониторингом; микросервис для расчёта маршрутов |
| Утилитарный | Решение личной или узкой практической задачи | Парсер выписок банка → CSV; скрипт резервного копирования с шифрованием; Telegram-бот для отслеживания сроков ГОСТов |
| Исследовательский | Эксперимент с архитектурой, алгоритмами, нетиповыми решениями | Реализация lock-free очереди; сравнение latency в gRPC vs REST на одном наборе данных |
Разграничение с близкими понятиями:
- Сайд-проект — может иметь коммерческую составляющую (например, SaaS с монетизацией), но не является основным местом работы.
- Фриланс-задача — выполняется по договору, даже если объём небольшой.
- Внутренний инструмент на работе — принадлежит работодателю, ограничен корпоративной политикой.
Методология создания пет-проекта
Play ITЗагрузка интерактивного демо…
Ниже — развёрнутая методология: от одной фразы "хочу попробовать Rust" до репозитория, который не стыдно показать на собеседовании. Каждый шаг можно проходить за один вечер или растянуть на недели; главное — завершать MVP, а не бесконечно переписывать стек.
1. Формулировка цели и scope
-
Задайте измеримую цель: "Реализовать CRUD API на ASP.NET Core 8 + EF Core 8 с покрытием unit-тестами ≥ 80 %", а не "Попробовать .NET".
"Попробовать" не заканчивается: нет критерия "готово". Измеримая цель позволяет отсечь лишнее и закрыть проект.
-
Определите границы: MVP должен быть завершаемым за 10–40 часов для типичного разработчика.
Если оценка ушла в 200 часов — урежьте scope (одна сущность, без админки) или разбейте на фазы.
-
Запишите критерии успеха (например: "проект задеплоен в Docker-контейнере на VPS", "есть OpenAPI-спецификация").
Это чек-лист приёмки для себя: без деплоя и README проект не считается завершённым для портфолио.
2. Выбор тематики
-
Соответствие текущему уровню: избегайте одновременного освоения трёх новых технологий (фронтенд + бэкенд + infra).
Один новый слой за проект (например, только React или только FastAPI) — иначе непонятно, где учиться при ошибке.
-
Потенциал расширения — начните с консольной утилиты, затем добавьте веб-интерфейс, API, мониторинг.
Консольный парсер CSV за вечер даёт победу; веб-оболочка — вторая итерация, а не обязательство в день один.
-
Практическая применимость — даже учебные проекты лучше строить вокруг реальных сценариев (например, обработка логов, валидация XML по XSD).
"Реальный" сценарий мотивирует довести до конца и даёт историю на собеседовании, а не абстрактный TODO №47.
3. Планирование и декомпозиция
Для проектов > 8 часов рекомендуется фиксировать план в виде:
-
Планы развития — этапы (Прототип → MVP → Тестирование → Документация → Публикация).
Видно, на какой фазе вы сейчас; не смешивайте "допилить UI" с "настроить DNS" в одной куче.
-
Backlog — задачи в формате — "Как [роль], я хочу [действие], чтобы [результат]".
User story держит фокус на ценности — "как пользователь хочу сбросить пароль, чтобы войти снова", а не "сделать метод SendEmail".
-
WBS (Work Breakdown Structure) — иерархическая декомпозиция (например:
API → Auth → JWT → Refresh token rotation).Дерево задач помогает оценить время по листьям и не забыть зависимости (сначала модель пользователя, потом JWT).
4. Технологический стек
Выбор должен служить цели проекта:
-
Для изучения инфраструктуры — предпочтительны IaC (Terraform, Pulumi), Docker, GitHub Actions.
Цель — pipeline и воспроизводимое окружение; бизнес-логика может быть минимальной.
-
Для проработки архитектуры — выделите слои —
domain,application,infrastructure,presentation.См. Организация кодовой базы: даже учебный API выигрывает от разделения "правила" и "БД".
-
Избегайте "модных" решений без понимания trade-off (например, Kafka ради одного события в сутки).
Сложность должна окупаться нагрузкой или командой; для пет-проекта достаточно очереди в БД или cron.
5. Инициализация проекта
-
Репозиторий: инициализация через
git init,.gitignore(с учётом стека —node_modules/,bin/,obj/).Первый коммит — "Initial commit" с
.gitignore, чтобы не залитьnode_modulesна 500 МБ. См. Git — как работать, пошаговый push на GitHub. -
Лицензия: даже для личного проекта — указание (MIT, Apache 2.0, Unlicense).
Без LICENSE правовой статус для форков и работодателя размыт; MIT — самый частый выбор для портфолио.
-
CI/CD: минимальный pipeline — сборка + запуск тестов (GitHub Actions, GitLab CI). Готовые YAML — CI/CD рецепты.
Достаточно workflow на
pushвmain:npm test/dotnet test. Падающий CI на GitHub — нормальный сигнал до merge. -
Версионирование:
v0.1.0по Semantic Versioning с первого коммита.Тег
v0.1.0на первом релизе в GitHub Releases учит дисциплине версий до боевого продукта.
6. Реализация
-
MVP-подход: реализуйте core-функционал без UI и продвинутой валидации.
API, который создаёт и читает заметку из JSON, уже MVP; красивый CSS — итерация 2.
-
Refactoring in small steps — каждая задача завершается локальным улучшением (extract method, rename, introduce interface).
Мелкие коммиты "переименовал", "вынес сервис" проще откатить, чем один "всё переделал".
-
Тестирование: начните с нескольких ключевых unit-тестов; не стремитесь к 100 % покрытию сразу.
Один тест на главное правило (скидка, валидация email) фиксирует поведение при рефакторинге.
-
Документация как артефакт:
README.mdв формате:
## Цель
## Стек
## Запуск (локально / Docker)
## Архитектура (диаграмма C4 Level 1 в виде текста или Mermaid)
## План развития
7. Публикация и развитие
-
GitHub/GitLab — открытый репозиторий → вклад в OSS, демонстрация workflow (issues, PR, code review имитация).
Публичный repo с историей коммитов и PR "как в команде" убедительнее zip-архива.
-
Размещение — бесплатно — Render, Vercel, Fly.io; условно бесплатно — Yandex Cloud, AWS Free Tier.
Статика — GitHub Pages; API — контейнер или PaaS с health-check.
-
Фидбек: приглашение коллег к code review (даже асинхронно).
Один взгляд со стороны ловит уязвимости и неочевидные имена; не обязательно merge, достаточно комментариев.
-
Поддержка: фикс критических уязвимостей (dependabot), обновление зависимостей раз в квартал.
Заброшенный repo с CVE в зависимостях хуже, чем честная пометка "архив"; Dependabot — минимум гигиены.
Профессиональная ценность пет-проектов
-
Подтверждение self-driven learning: работодатели рассматривают живые репозитории как индикатор инициативности.
Видно, что вы сами ставили задачу, оценивали сроки и довели до демо — навык, который в команде ценят не меньше синтаксиса языка.
-
Практика полного цикла: от архитектуры до деплоя — опыт, недоступный в узкоспециализированных корпоративных ролях (выкладка на GitHub Pages для статики и портфолио).
На работе вы могли годами только "дописывать endpoint"; пет-проект даёт картину "от
git initдо URL в браузере". -
Снижение рисков экспериментов: проверка гипотез (например, "насколько сложно перейти с REST на GraphQL") без воздействия на production.
Неудачный эксперимент — удалённая ветка, а не инцидент P1.
-
Формирование технического мышления: необходимость самостоятельно принимать trade-off решения (performance vs maintainability, consistency vs availability).
В пет-проекте нет архитектора "сверху" — вы сами решаете, нужен ли Redis; это тренирует аргументацию решений.
Важно — пет-проекты не заменяют коммерческий опыт, но компенсируют его отсутствие при смене направления (например, переход в high-load разработку) или входе в IT.
Типовой маршрут на 4 недели (учебный MVP)
Ориентир для занятого графика (~6–8 часов в неделю):
| Неделя | Цель | Артефакты |
|---|---|---|
| 1 | Идея + каркас | README с целью, git init, пустой API или CLI "hello" |
| 2 | Core | Один сценарий end-to-end (создать / прочитать сущность) |
| 3 | Качество | 3–5 тестов, .gitignore, линтер по желанию |
| 4 | Публикация | push на GitHub, деплой статики или Docker, скриншот в README |
Если застряли на выборе стека — возьмите стек из Плана развития (калькулятор, To-Do, погода) и не меняйте его до конца MVP.
Антипаттерны пет-проектов
| Антипаттерн | Почему вредно | Что делать вместо |
|---|---|---|
| "Сначала идеальная архитектура" | Нет рабочего демо через месяц | MVP в одной папке, рефакторинг после |
| Три новых технологии сразу | Непонятно, где ошибка | Одна новинка + знакомый стек |
| Нет README и скриншота | Ревьюер на hh не откроет репозиторий | README, GIF или скрин |
| Секреты в репозитории | Риск блокировки аккаунта API | .env локально, пример .env.example |
| Бросить на 90 % | В портфолио не попадает | Закрыть "дыру" — деплой или демо-видео |
Что показать работодателю в README
Минимальный блок в начале README (подробнее — README для разработчика):
- Что делает проект (одно предложение).
- Стек и почему выбран.
- Как запустить локально (команды копипастой).
- Скриншот или ссылка на демо.
- Что бы сделали дальше (2–3 пункта backlog) — показывает зрелость, а не "забросил".
Пошаговый деплой статического сайта на GitHub Pages (репозиторий, домен, Actions, deploy.yml) — лабораторный кейс "Размещение своего сайта с GitHub Pages".
Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.