Глава 24 · Что дальше? Roadmap Python-разработчикаПортфолио разработчика
Осмысленные проекты с доказательствами запуска, проверки и архитектурных решений, а не коллекция повторённых учебных работ.
Портфолио показывает решения
Репозиторий полезен, когда другой разработчик может понять задачу, запустить проект, проверить основные свойства и увидеть, почему архитектура выглядит именно так. Количество проектов не компенсирует отсутствие завершения и объяснения.
Учебные повторы и инженерное портфолио
| Учебные повторы | Инженерное портфолио |
|---|---|
| Повторяет заранее заданные шаги и известный результат. | Начинается с самостоятельно сформулированной проблемы, пользователя и границ. |
| Показывает только финальный код или снимок экрана. | Даёт воспроизводимую установку, демонстрацию, тесты и проверяемый релиз. |
| Скрывает ход изменений и причины решений. | Сохраняет историю Git, Issues, небольшие PR и описание архитектурных компромиссов. |
| Сложно отличить авторские решения от инструкции. | README и documentation объясняют вклад автора, ограничения и дальнейшую работу. |
Лестница зрелости проекта
| Уровень | Что видно в проекте | Проверяемый результат |
|---|---|---|
| Level 1 | Скрипт решает одну задачу локально. | Автор может воспроизвести результат. |
| Level 2 | Есть функции, структура каталогов, README и обработка ожидаемых ошибок. | Новый пользователь запускает проект по инструкции. |
| Level 3 | Критическая логика покрыта тестами; lint и CI повторяют локальную проверку. | Изменение проходит автоматическую проверку качества. |
| Level 4 | Есть ясные интерфейсы, конфигурация, наблюдаемость, сборка пакета и примечания к релизу. | Артефакт ставится в чистой среде и диагностирует отказ. |
| Level 5 | Описаны компромиссы, ограничения, модель угроз или отказов и эксплуатационный сценарий. | Решение можно обсуждать как инженерную систему. |
Эта лестница описывает зрелость демонстрации, а не ранг разработчика. Не каждому проекту нужен Level 5. Один глубокий проект может его достигнуть, а два меньших покажут разнообразие задач.
Как отбирать проекты
Универсального количества проектов и тем более гарантии найма не существует. Выберите минимальный набор, который показывает общий фундамент, выбранную специализацию и качество инженерного процесса. Состав может быть таким:
- один небольшой CLI или библиотека с чистым API и пакетом;
- один основной проект специализации с реальной границей: БД, GUI, data pipeline или game loop;
- один проект, где особенно видны тестирование, CI и диагностика;
- при необходимости один командный или open-source вклад;
- необязательный эксперимент, показывающий исследовательский интерес.
Что должно быть в каждом репозитории
Что должен найти читатель
- README с постановкой проблемы, пользователем, границами решения и статусом проекта.
- Снимки экрана или короткую демонстрацию, подтверждающие основной сценарий без подмены технического описания.
- Воспроизводимую установку: версии, зависимости, команды установки, запуска, тестов и сборки.
- Архитектурную схему, интерфейсы, ключевые компромиссы и известные ограничения.
- Тесты критической логики и CI, повторяющий локальную проверку качества.
- Историю Git, Issues и небольшие изменения, по которым виден ход инженерных решений.
- Версионированный релиз или устанавливаемый артефакт с примечаниями к релизу.
- LICENSE и документацию, достаточные для заявленного способа использования.
Не усложняйте проект ради списка технологий
Не добавляйте Kubernetes, брокер сообщений, микросервисы или нейросеть ради списка технологий. Добавляйте компонент, когда можете сформулировать требование, альтернативы, стоимость и способ проверки. История небольших осмысленных PR делает развитие проекта понятнее, чем один гигантский commit.