Пет-проекты

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Инженеру

Пет-проект

Пет-проект (от pet project) — программный проект, инициированный и реализуемый разработчиком в личное время, без внешнего заказа, коммерческого контракта или корпоративного ТЗ. Цель проекта определяется инициатором автономно.

Ключевые признаки:

• Отсутствие формального SOW (Statement of Work), SLA, KPI.
• Собственническое право на кодовую базу и артефакты.
• Гибкий жизненный цикл: может быть завершён, заморожен, перепроектирован или открыт как OSS.
• Технологический выбор не ограничен корпоративными стандартами.

Классификация по мотивации:

Тип	Цель	Примеры
Обучающий	Освоение новой технологии, парадигмы, инструмента	Реализация HTTP-сервера на сокетах; SPA на Svelte; CLI-утилита на Rust
Демонстрационный	Формирование портфолио, подтверждение компетенций	Full-stack блог с аутентификацией, CI/CD, мониторингом; микросервис для расчёта маршрутов
Утилитарный	Решение личной или узкой практической задачи	Парсер выписок банка → CSV; скрипт резервного копирования с шифрованием; Telegram-бот для отслеживания сроков ГОСТов
Исследовательский	Эксперимент с архитектурой, алгоритмами, нетиповыми решениями	Реализация lock-free очереди; сравнение latency в gRPC vs REST на одном наборе данных

Разграничение с близкими понятиями:

• Сайд-проект — может иметь коммерческую составляющую (например, SaaS с монетизацией), но не является основным местом работы.
• Фриланс-задача — выполняется по договору, даже если объём небольшой.
• Внутренний инструмент на работе — принадлежит работодателю, ограничен корпоративной политикой.

---

Методология создания пет-проекта

1. Формулировка цели и scope

• Задайте измеримую цель: «Реализовать CRUD API на ASP.NET Core 8 + EF Core 8 с покрытием unit-тестами ≥ 80 %», а не «Попробовать .NET».
• Определите границы: MVP должен быть завершаемым за 10–40 часов для типичного разработчика.
• Запишите критерии успеха (например: «проект задеплоен в Docker-контейнере на VPS», «есть OpenAPI-спецификация»).

2. Выбор тематики

• Соответствие текущему уровню: избегайте одновременного освоения трёх новых технологий (фронтенд + бэкенд + infra).
• Потенциал расширения: начните с консольной утилиты, затем добавьте веб-интерфейс, API, мониторинг.
• Практическая применимость: даже учебные проекты лучше строить вокруг реальных сценариев (например, обработка логов, валидация XML по XSD).

3. Планирование и декомпозиция

Для проектов > 8 часов рекомендуется фиксировать план в виде:

• Планы развития — этапы (Прототип → MVP → Тестирование → Документация → Публикация).
• Backlog — задачи в формате: «Как [роль], я хочу [действие], чтобы [результат]».
• WBS (Work Breakdown Structure) — иерархическая декомпозиция (например: API → Auth → JWT → Refresh token rotation).

4. Технологический стек

Выбор должен служить цели проекта:

• Для изучения инфраструктуры — предпочтительны IaC (Terraform, Pulumi), Docker, GitHub Actions.
• Для проработки архитектуры — выделите слои: domain, application, infrastructure, presentation.
• Избегайте «модных» решений без понимания trade-off (например, Kafka ради одного события в сутки).

5. Инициализация проекта

• Репозиторий: инициализация через git init, .gitignore (с учётом стека: node_modules/, bin/, obj/).
• Лицензия: даже для личного проекта — указание (MIT, Apache 2.0, Unlicense).
• CI/CD: минимальный pipeline — сборка + запуск тестов (GitHub Actions, GitLab CI).
• Версионирование: v0.1.0 по Semantic Versioning с первого коммита.

6. Реализация

• MVP-подход: реализуйте core-функционал без UI и продвинутой валидации.
• Refactoring in small steps: каждая задача завершается локальным улучшением (extract method, rename, introduce interface).
• Тестирование: начните с нескольких ключевых unit-тестов; не стремитесь к 100 % покрытию сразу.
• Документация как артефакт: README.md в формате:

  ## Цель
  ## Стек
  ## Запуск (локально / Docker)
  ## Архитектура (диаграмма C4 Level 1 в виде текста или Mermaid)
  ## План развития

7. Публикация и развитие

• GitHub/GitLab: открытый репозиторий → вклад в OSS, демонстрация workflow (issues, PR, code review имитация).
• Размещение: бесплатно — Render, Vercel, Fly.io; условно бесплатно — Yandex Cloud, AWS Free Tier.
• Фидбек: приглашение коллег к code review (даже асинхронно).
• Поддержка: фикс критических уязвимостей (dependabot), обновление зависимостей раз в квартал.

---

Профессиональная ценность пет-проектов

• Подтверждение self-driven learning: работодатели рассматривают живые репозитории как индикатор инициативности.
• Практика полного цикла: от архитектуры до деплоя — опыт, недоступный в узкоспециализированных корпоративных ролях.
• Снижение рисков экспериментов: проверка гипотез (например, «насколько сложно перейти с REST на GraphQL») без воздействия на production.
• Формирование технического мышления: необходимость самостоятельно принимать trade-off решения (performance vs maintainability, consistency vs availability).

Важно: пет-проекты не заменяют коммерческий опыт, но компенсируют его отсутствие при смене направления (например, переход в high-load разработку) или входе в IT.

---