В прошлом году Джош Комо, автор туториалов и учебных материалов для разработчиков, на своем аккаунте в Твиттере вызвался посмотреть и покритиковать сайты-портфолио всех желающих. В ходе мероприятия он заметил интересную вещь: обратная связь получалась не очень разнообразной, недоработки при оформлении портфолио у большей части начинающихся программистов оказывались примерно одни и те же. Тогда у Комо и возникла мысль о том, что неплохо бы собрать часто повторяющиеся замечания в один список. В итоге у него получился довольно обширный материал, который был оформлен в электронную книгу – она доступна на сайте автора бесплатно. Под катом вы найдете основные тезисы, рекомендации и источники, которые в ней приводятся.
Общие вопросы
Что подразумевается под портфолио разработчика?
В большинстве случаев речь идет о сайте, где представлены личные проекты, по которым можно судить о его опыте и навыках.
Это обязательно?
Нет. Далеко не все разработчики включают портфолио в резюме и далеко не все работодатели ждут такой информации. Более того, есть и такие, кто даже не станет открывать ссылку. Портфолио опционально, но оно может дать неплохое преимущество перед конкурентами и максимально наглядно показать, что вы умеете.
Разве нет других способов продемонстрировать свою работу?
Есть. В резюме сейчас часто включают, допустим, ссылки на 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, который произвел на него самое приятное впечатление на фоне других, присланных подписчиками. Сравнивая один с другим, легко заметить, как они соотносятся с рекомендациями.
Сайт Чарли – невыразительный дизайн без изюминок, шаблонный рассказ о себе, краткое и поверхностное описание проектов
Сайт Джулии – более эффектный дизайн, удачная структура, сдержанный, но не безликий рассказ о себе, много элементов, оживляющих страницу, подробные описания для каждого проекта
