Как стать автором
Обновить
108.76
Рейтинг
Productivity Inside
Для старательного нет ничего невозможного

Портфолио разработчика по Джошу Комо: структура, наполнение, смысл

Блог компании Productivity Inside Карьера в IT-индустрии


В прошлом году Джош Комо, автор туториалов и учебных материалов для разработчиков, на своем аккаунте в Твиттере вызвался посмотреть и покритиковать сайты-портфолио всех желающих. В ходе мероприятия он заметил интересную вещь: обратная связь получалась не очень разнообразной, недоработки при оформлении портфолио у большей части начинающихся программистов оказывались примерно одни и те же. Тогда у Комо и возникла мысль о том, что неплохо бы собрать часто повторяющиеся замечания в один список. В итоге у него получился довольно обширный материал, который был оформлен в электронную книгу – она доступна на сайте автора бесплатно. Под катом вы найдете основные тезисы, рекомендации и источники, которые в ней приводятся.

Общие вопросы


Что подразумевается под портфолио разработчика?

В большинстве случаев речь идет о сайте, где представлены личные проекты, по которым можно судить о его опыте и навыках.

Это обязательно?

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

Разве нет других способов продемонстрировать свою работу?

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

Для кого предназначены эти советы?

Для разработчиков-джуниоров, которым, с одной стороны, уже есть что показать, а с другой – хочется компенсировать в глазах работодателя недостаток рабочего опыта и выделиться из общей массы. Автор ориентируется, прежде всего, на фронтенд и фулстек, однако большая часть рекомендаций будет полезна также и тем, кто занимается бэкендом или мобильной разработкой.

Сколько проектов должно быть на сайте?

Оптимальное количество – от двух до пяти. Подход «чем больше, тем лучше» тут не работает – портфолио рассчитано на то, чтобы продемонстрировать самые удачные образцы работы, а не охватить всю хронологию. Если очень хочется показать побольше, по крайней мере, ранжируйте их – пусть самые лучшие висят на главной странице, а остальные открываются по клику на кат «Показать еще» или вкладку с архивом.

Если проект только один, но масштаб и качество у него достойные, допустимо добрать количество за счет чего-то менее впечатляющего: сделать простенький продукт чисто для портфолио или небольшую вариацию на тему основного (например, расширение на базе мобильного приложения), указать текущий проект с пометкой «В процессе», рассказать о какой-то деятельности, не связанной напрямую с кодом (документации, организации мероприятий для разработчиков).

Какие проекты включать нельзя?

Есть несколько категорий проектов, которые следует использовать с большой осторожностью:

  • Всё, что сделано по инструкции – скажем, с опорой на туториал или в ходе воркшопа. В таких проектах слишком велик вклад человека, который вас направлял, они не дают четкого представления о том, что вы умеете делать самостоятельно. К тому же можно нажить проблемы с авторскими правами. Проект можно считать своим, только если вы использовали чужой материал как отправную точку и очень существенно (на 50% и более) его расширили или переработали.
  • Проекты с предыдущих или текущего места работы. Причина здесь очевидна – велик риск нарушить соглашение о неразглашении. Если все же решаетесь разместить рабочий проект на сайте, обязательно обсудите все подробности и узкие места с работодателем.
  • Сам сайт-портфолио. Обычно это производит удручающее впечатление – как будто разработчик не нашел среди своих работ ничего более яркого. Исключение составляют случаи, когда вы реализовали что-то сложное и нетривиальное под капотом. Если же кроме того, что посетитель видит невооруженным глазом, показать нечего, то на уровень портфолио сайт сам по себе не тянет.
  • Проекты, не имеющие отношения к разработке. Все прочие умения и увлечения лучше оставить для раздела «О себе». Комо также не рекомендует уделять слишком много внимания своим навыкам в смежных областях, вроде графического дизайна или написания технических текстов. Это несколько меняет жанр сайта, создавая ощущение, что вы занимаетесь фрилансом и работаете по краткосрочным контрактам. Работодатель, который ищет сотрудника на постоянную основу, может сделать неверные выводы о ваших предпочтениях.


Какие проекты стоит включать в первую очередь?

Помимо очевидного (хорошие и интересные), есть несколько характеристик, которые работодатели склонны ценить особенно высоко:

  • Целевые проекты, которые создавались для решения конкретной частной проблемы. Они показывают, что вы умеете переложить технические навыки на практическую почву, и позволяют оценить ваш подход ко всем аспектам ведения проекта, от начала до конца.
  • Живые проекты, у которых есть реальные пользователи, пусть даже немного, как правило, вызывают больше интереса, чем демо-версии продуктов, которые делались ради самого процесса.
  • Масштабные, сложные проекты, на которые ушло много времени и сил. Не каждый джуниор в принципе в силах довести нечто подобное до конца, так что сам факт наличия будет говорить в вашу пользу.
  • Вклады в популярные библиотеки с открытым кодом. Это своего рода признание со стороны сообщества, подтверждение, что вы способны работать с чужим кодом, ставить перед собой задачи и взаимодействовать с другими программистами. Само собой, необходимо очень четко прописать, какие именно изменения вы вносили, чтобы случайно не присвоить себе чужую работу.

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

Структура и наполнение сайта


У сайтов-портфолио обычно не слишком разветвленная структура. По сути, она сводится к набору следующих смысловых блоков: раздел «О себе», список/сетка проектов, с развернутыми описаниями для каждого, контакты. Далее мы рассмотрим каждый из них в отдельности.

О себе

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

Раздел «О себе» предназначен в большей степени для кадровиков. Основная его задача – сделать ваше «личное дело» хоть немного запоминающимся на фоне других. На взгляд автора, главный бич сайтов-портфолио сейчас – полная обезличенность, стремление вписаться в корпоративный стиль, который использует один и тот же структурный костяк (закончил такой-то университет, работал или работаю там-то, владею такими-то технологиями) и набор речевых клише.

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

Разработчики редко проявляют интерес к этому разделу, так что для них лучше вынести список языков и технологий, с которыми вы работаете, куда-нибудь на видное место.

Выбирая тон своего рассказа, имейте в виду еще один момент: кадровики и разработчики смотрят на ваши мягкие навыки джуниоров сквозь разные призмы. Кадровики скорее оценят энтузиазм и увлеченность своим делом. Для разработчиков в первую очередь важна адекватная самооценка – им еще предстоит вас обучать. Поэтому, расписывая свою любовь к коду, старайтесь не впадать в излишний апломб. Если вы представляете себя как сложившегося специалиста и аса разработки, кадровики, может, и проникнутся вашей уверенностью, но будущие наставники, скорее всего, подумают, что работать с вами будет тяжело.

Проекты и их описания

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



Каждая такая карточка обязательно должна переводить на страницу с подробным описанием. Если информация исчерпывается перечисленными пунктами, смысл сайта-портфолио, по сути, теряется.

Рассчитывать, что продукт будет говорить за себя сам – серьезная ошибка, которую совершают многие разработчики. «Продавать» свою работу считается неуместным, поэтому дело ограничивается ссылкой на демо-версию и, в идеальном сценарии, кодовую базу – работодателю предоставляется возможность самому составить мнение.

Критических недостатков у такого подхода два. Во-первых, без вашего курирования взаимодействие посетителя сайта с продуктом становится непредсказуемым. Вам будет очень сложно заранее угадать, как будет проходить пользовательское путешествие и на каком моменте оно прервется, особенно если вы никогда не занимались UX-дизайном. Человек может просто не добраться именно до тех вещей, которыми вы больше всего гордитесь и на которые делаете ставку.

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

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

Комо предлагает план, на который можно опираться при написании текста о проекте. Необязательно раскрывать все пункты, сосредоточьтесь на тех, о которых действительно есть что сказать.

Введение

  • Общий обзор, суть проекта
  • Список основных функций и отличительных особенностей
  • Ваша роль в проекте: работали в одиночку или в группе, какие именно вещи реализованы вашими силами?
  • Технологии, которые применялись
  • Ссылка на демо-версию и кодовую базу (по возможности)

Цели и основания

  • Почему вы взялись за этот проект, какова его значимость лично для вас?
  • Что предполагалось на старте, каким был продукт на этапе проектирования?
  • Любые другие замечания, касающиеся стадии планирования.

Ключевые моменты

  • Что в проекте больше всего впечатляет с точки зрения технического исполнения? Ответы могут быть самыми разными – хоть система аутентификации, хоть элементы интерфейса, хоть подтягивание информации из базы данных.
  • Сложности, с которыми вы столкнулись в процессе.
  • Пути решения возникающих проблем, ход мысли при выборе стратегии, результаты. Здесь нужен хороший, глубокий анализ, написанный в расчете на то, что читать будут разработчики.

Выводы

  • Чему вы научились в ходе работы над проектом? К чисто техническим открытиям можно добавить и что-то не связанное напрямую с кодом, например, какие-то подробности управления проектом или организации релиза.
  • Правильно ли вы выбрали инструменты, фреймворки, библиотеки? Что в стеке вам особенно помогло? Каких возможностей не хватало?
  • Повлиял ли приобретенный опыт на вашу дальнейшую работу? Если удастся связать два проекта, указав, как знания, приобретенные в одном, пригодились в другом, будет просто отлично.


Текущий статус – опциональная секция. Ее имеет смысл включить, если продуктом в реальности кто-то пользуется; тогда можно упомянуть, какая у него аудитория и что говорят люди. Если проект делался специально для портфолио, распространяться об этом не стоит.

Текста, скорее всего, получится довольно много – описание одного проекта может занимать две-три страницы. Чтобы повысить шансы на то, что читатель дойдет до конца, адаптируйте его под чтение по диагонали: короткие абзацы, заголовки, списки.

Контакты

Как правило, в этом блоке представлена форма обратной связи. Если вам удобнее общаться по электронной почте, можно ограничиться прямой ссылкой mailto. Сюда же выносятся ссылки на страницы в соцсетях и профессиональный блог, если вы его ведете. Сейчас наметилась тенденция встраивать блог непосредственно в сайт-портфолио, но автор относится к этой идее скептически. Портфолио заточено в первую очередь под общение с работодателем – вероятность того, что он найдет время на чтение постов, крайне мала. Кроме того, вам придется особенно пристально следить за регулярностью обновлений и качеством контента.

Техническая реализация


Дизайн

Сначала о грустном: дизайн имеет большой вес. Контент контентом, но особенности зрительного восприятия работают без перебоев, поэтому чем красивее (даже не удобнее, именно красивее) сайт, тем более профессионально вы будете выглядеть в глазах посетителей.

Далеко не все разработчики сильны в дизайне или могут позволить себе заказной, так что оптимальным по ресурсозатратности к результату вариантом представляется использование готовых шаблонов. Самое лучшее – отобрать несколько и сделать микс из них, чтобы интерфейс смотрелся более-менее свежо.

Комо отмечает, что в ходе своего массового просмотра портфолио неоднократно сталкивался с одним и тем же популярным дизайном, просто скопированным пиксель в пиксель:



Так делать точно не надо. Даже если дизайн в открытом доступе, это оставляет неприятное ощущение вторичности и вызывает вопросы насчет легальности заимствования.

Вот ряд шаблонов, на которые можно опираться при создании дизайна:

Portfolio Starter
Craig Portfolio
Alex Portfolio
Dexter Portfolio
Novo
Kester
Art Director

Разработка сайта

Если вы претендуете на должность фронтендера или фуллстек-разработчика, делать сайт нужно своими силами, без nocode-решений – положение обязывает. Инструменты можно использовать любые, лучше всего те, с которыми вы хорошо знакомы, чтобы не тратить лишнего времени. Как варианты можно рассмотреть: ванильные HTML/CSS/JS, 11ty, Gatsby, Next, Jekyll. Лично от себя автор рекомендует Gatsby, не в последнюю очередь за то, что для него сделано много тем и плагинов, сильно экономящих усилия.

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

Доменное имя

В идеале это должно быть что-то в духе имяфамилияналатинице.com. При необходимости (например, если имя уже занято) можно вставить элемент code или dev. Ники использовать нежелательно, если только вы не видная персона в онлайн-сообществе.

Домены верхнего уровня можно выбирать на свой вкус (co, io, специфические домены разных стран). Единственный момент: стоит избегать .info, который у многих ассоциируется со спамом и мошенниками.

Хостинг

Сайты-портфолио обычно статические, так что проблем с серверами они не создают. Для хостинга статических сайтов существует целый ряд сервисов, среди которых Комо выделяет Vercel, Netlify, Github Pages, Surge.

*

В дополнение к теории для наглядности Комо приводит два примера портфолио с подробным разбором. Первый – сайт Чарли Смит, вымышленного лица, который автор сделал сам, ориентируясь на типичный, усредненный образец из Сети. Второй – сайт Джулии Джонсон, студентки и стажерки IBM, который произвел на него самое приятное впечатление на фоне других, присланных подписчиками. Сравнивая один с другим, легко заметить, как они соотносятся с рекомендациями.



Сайт Чарли – невыразительный дизайн без изюминок, шаблонный рассказ о себе, краткое и поверхностное описание проектов



Сайт Джулии – более эффектный дизайн, удачная структура, сдержанный, но не безликий рассказ о себе, много элементов, оживляющих страницу, подробные описания для каждого проекта
Теги: портфолиосайт разработчикапоиск работытрудоустройство
Хабы: Блог компании Productivity Inside Карьера в IT-индустрии
Всего голосов 4: ↑3 и ↓1 +2
Комментарии 0
Комментарии Комментировать

Похожие публикации

Лучшие публикации за сутки