Почти у каждого разработчика есть GitHub, полный проектов, которые ничему его не научили:
- todo-app
- crud-app
- netflix-clone
Проблема не в самих проектах. Проблема в том, что они ничего нового не требуют от разработчика. Не требуют шевеления мозгами.
Большинство проектов создаются не для роста, а для ощущения прогресса.
Код пишется. Репозиторий существует. Галочка поставлена. Навыков - почти не прибавилось.
Главная ошибка - разработчики делают проекты, которые ничему новому не учат.
- Очередной CRUD-сервис
Ты уже понимаешь принцип после первого раза. Следующие десять проектов лишь повторяют знакомый паттерн. - Todo List №47
Не делает тебя сильнее. Он лишь подтверждает, что ты умеешь копировать архитектуру из туториала.
В таких проектах отсутствует реальная сложность - ты тренируешь набор команд, но не мышление. Настоящий рост начинается там, где нет готового видео «сделаем приложение за 15 минут».
Что же отличает полезный pet-проект?
Хороший проект решает проблему, а не демонстрирует стек технологий. Он заставляет тебя столкнуться с вопросами:
- Что произойдёт при росте нагрузки?
- Как будет происходить обновление данных?
- Как тестировать систему?
- Как она будет развиваться через полгода?
Если проект не вызывает архитектурных вопросов - он почти бесполезен.
Какие проекты действительно развивают
Архитектурные проекты
- сервис с очередями и асинхронной обработкой
- система кэширования
- event-driven приложение
- мини-платформа с несколькими сервисами
Здесь главная задача - понять взаимодействие компонентов, а не написать контроллер.
Проекты с реальными ограничениями
- rate limiting
- авторизация и роли
- обработка ошибок
- логирование и мониторинг
- работа с отказами
Реальная разработка начинается там, где всё перестаёт работать идеально.
Проекты, которые живут
Большинство pet-проектов делаются одним коммитом и сразу же умирают. Реально хороший и полезный проект:
- развивается
- рефакторится
- ломается
- переписывается
Именно это формирует инженерное мышление.
Если ты пишешь pet-проекты для портфолио, запомни - ни рекрутеру, ни работодателю не нужен очередной todo list. Он ищет признаки зрелости разработчика.
Проект в резюме должен показывать:
- архитектурные решения
- структуру проекта
- понятные README и документацию
- тесты
- осмысленные коммиты
- объяснение, почему система устроена именно так.
Важно не количество проектов, а глубина одного. И помни, по-настоящему хороший pet-проект нужен не для GitHub или работодателя - он нужен для тебя.