Open Source для джуна: куда вписаться, чтобы пополнить портфолио

Участие в open-source-проектах расширяет кругозор джуна, а для начинающего разработчика это главный буст к развитию.

Но прежде чем погружаться в GitHub, поймите две вещи:

• Контрибьюшен — это не только когда вы пишете и добавляете код. В это понятие входит любой полезный контент в репозиториях. Можно открывать issue, писать и фиксить документацию, участвовать в обсуждениях и так далее.
• Большие open-source-проекты работают по очень сложным правилам и включают сложные процессы.

Если джун разберётся, как работать с Open Source, коммерческие проекты покажутся гораздо более простыми. Кстати, есть проекты, которые помогают вкатиться в Open Source. Например, «Культ марсиан» — там собраны интересные задачи для веб-программистов.

Влад Шилов: «Начинающим разработчикам Open Source поможет выделиться из толпы»

Влад Шилов

В Twitter известен как @omgovich. Frontend-инженер из Ростова-на-Дону. Член программного комитета конференции HolyJS, автор open-source-библиотек react-colorful и colord, ведущий подкаста Goose & Duck Open Source.

После пандемии и победы удалёнки на рынке появилось ещё больше начинающих разработчиков. Большинство из них прошли какие-то курсы и пытаются найти первую работу в IT. У некоторых это получилось, и теперь на рынке слишком много junior-специалистов с условным годом опыта.

Когда я работал СТО в digital-агентстве, то почти каждый день просматривал десятки резюме новичков. Все выглядели почти одинаково: имя, фамилия, почта, учился в таком-то университете, опыта в IT нет, базовый набор скиллов, инициативный, ответственный. Всё!

При этом заметил любопытную закономерность: почти во всех резюме стояла ссылка на GitHub-профиль кандидата. Но в 80% случаев профиль оказывался абсолютно пустым: не было никаких личных проектов или записей об активности в проектах других разработчиков. В 15% профилей можно было найти пару устаревших результатов тестовых заданий, которые чаще всего кандидат делал, когда искал работу в прошлый раз. Лишь в редких случаях я находил актуальные pet-проекты, которые позволяли понять, как человек пишет код и строит свои приложения.

Помню, я тогда очень раздражался из-за пустых GitHub-профилей. Не мог понять: зачем люди добавляют ссылки на них в резюме и на какие выводы с моей стороны вообще рассчитывают?

Сейчас я почти не нанимаю людей, но работаю в международном продукте, который предоставляет сервисы для создания резюме и поиска работы. В куче наших статей и гайдов можно встретить фразу «Stand out from the crowd» — «Выделяйся из толпы». Начинающим разработчиками без коммерческого опыта или тем, у кого его мало, выделиться поможет Open Source.

Не обязательно что-то изобретать и делать собственные проекты с нуля. Найдите репозиторий интересной вам библиотеки и помогите её улучшить. Не обязательно даже делать какие-то крупные фичи: можно, например, починить баг, на который у автора библиотеки не хватает времени, помочь написать или перевести документацию.

От такой деятельности одни плюсы:

• Вы оживите свой GitHub-профиль — техническому специалисту, проверяющему ваше резюме, будет что посмотреть.
• Сумеете написать в резюме, какую пользу комьюнити сумели принести и в каких проектах участвовали. Это компенсирует нехватку опыта и позволит выделиться на фоне других кандидатов.
• Работая с кодом популярных open-source-библиотек, вы узнаете, как писать хороший код и тесты, как строить архитектуру, какие инструменты разработки существуют и так далее.

Не думайте, что если вы новичок, то во взрослом Open Source вам нечего делать — это совершенно не так. Например, в двух моих популярных open-source-проектах (больше трёх миллионов скачиваний в неделю) многие фичи и улучшения отправляли студенты.

Поддержка open-source-проектов съедает много времени, и авторы популярных библиотек зачастую просто не успевают решить все проблемы. Если вы можете им помочь, набраться опыта и сделать своё резюме богаче — почему бы не попробовать?

Никита Однороб: «Пробуйте себя в Open Source, ищите good first issue и реализуйте их»

Никита Однороб

В Twitter @nikita_frondev. Фронтенд-разработчик в TradingView. Пишет на JS и React. Любит футбол, снукер и космос.

Поработать над открытыми проектами — это отличная идея. Если вы хотите попробовать Open Source, но не уверены в себе, начните с малого: улучшайте документацию, исправляйте несложные ошибки, пишите тесты или простые фичи.

У такого подхода есть несколько преимуществ:

1. Даже без опыта и глубоких знаний вы сможете внести вклад в проект.
2. Несмотря на простоту, такие задачи позволяют пройти весь цикл разработки в Open Source: изменяете/пишете код → создаёте pull request → проходите код-ревью.
3. Даже такие, на первый взгляд несущественные, изменения помогают проекту. Как правило, авторы сосредоточены на добавлении новых фич, а на покрытие кода тестами и красивое оформление документации не остаётся времени.
4. Когда ваши изменения вольют в основную ветку, будет приятно осознавать, что вы причастны к большому проекту. Каждый новый влитый pull request придаст уверенности в своих силах.

Но всё же новичкам не стоит контрибьютить в первый попавшийся проект. Например, не советую выбирать репозитории, в которых давно не было обновлений. Возможно, их авторам будет не до вас, вы не получите код-ревью и даже хоть какой-то реакции на pull request. Также посмотрите на список issue проекта. Если в репозитории много issue, заведённых уже несколько месяцев назад, — это плохой знак.

А вообще, в open-source-проектах есть много issue на несложные задачи, до которых у авторов просто не доходят руки. Их иногда помечают как good first issue. Это означает, что, по мнению автора, задача несложная и, скорее всего, с ней справится даже начинающий разработчик. Например, такие issue появляются, если нужно добавить новую локализацию или обновить документацию.

Рассмотрим проект jest. Достаточно популярный npm-пакет — 12 млн скачиваний в неделю. На данный момент у него 23 issue с меткой good first. При этом закрытых issue с такой же меткой — 200. Большинство из них — по документации или тестам.

Есть сайт goodfirstissue, который показывает популярные репозитории с такими задачами. Например, когда я выбрал TypeScript, он показал, что в пакете react-use пять дней назад создали issue об ошибке сторибука с меткой good first и кто-то даже сделал pull request. Начинать вносить вклад в Open Source стоит с больших проектов — там много опытных участников, которые помогут и дадут код-ревью.

Ваш код не обязательно сразу попадёт в main — возможно, авторы репозитория попросят вас что-то подправить. Рекомендую доводить свои pull request до мерджа. Например, в проекте jest есть good first issue, открытое более года назад. Для него сделали два pull request — в каждом из них владелец репозитория предложил что-то исправить, но оба до сих пор висят незавершённые и с конфликтами: инициаторы просто забросили их.

Ваши pull request могут посмотреть не сразу — не переживайте по этому поводу. Если ожидание сильно затянулось, а автор репозитория при этом продолжает работать над проектом, упомяните его в issue или pull request.

Итак, резюмируем:

1. Пробуйте себя в Open Source, ищите good first issue и реализуйте их.
2. Если ревьюер попросил вас что-то подправить, лучше сделайте это и не оставляйте висячие pull request.
3. Не расстраивайтесь, если ваш pull request посмотрят не сразу.
4. Не расстраивайтесь, если ваши изменения отклонили. Попробуйте найти другую задачу.
5. Ваши изменения влили в основную ветку? Вы молодец! Можете собой гордиться.