Перейти к основному содержимому

4.14. Пет-проект

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ
Разработчику Архитектору Инженеру

Пет-проект​

Пет-проект (от 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 часов рекомендуется фиксировать план в виде:

  • Roadmap — этапы (Прототип → 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.