Привет, Хабр! Меня зовут Александр Водолазских. Я руковожу направлением разработки интерфейсов в СберМаркете и после работы люблю посидеть за кодом, разрабатывая собственные пет проекты.
Чего я только не кодил по вечерам — писал смарт-контракты на Solidity, копался с разными фреймворками и библиотеками, пилил своего убийцу Twitter на React.js... В моменты, когда фронтенд мне поднадоедал, я начинал писать сервисы на Node, Nest и даже на Go. А после — начал экспериментировать с мобильной разработкой на Swift.
Недавно я задумался о том, как сделать процесс разработки пет-проектов более полезными для моей карьеры, взглянул на ситуацию со стороны и скорректировал свой подход.
Мой сегодняшний текст — о том, как, мне кажется, нужно и, наоборот, нельзя вести пет-проекты. У меня получилось семь вредных советов. Надеюсь, вы тоже любили эту книгу Григория Остера в детстве. Если вы с ней не знакомы, концепция состоит в том, что дети часто вредничают и делают всё наоборот, поэтому нужно давать им советы от противного.
Посмотрите, как здорово этот формат адаптируется под айтишку:
Совет #1. Зачем вообще нужны пет-проекты, если можно просто овертаймить
Есть время вечером? Так посидите над своим основным проектом. Менеджеры будут счастливы! А вы — сгорите.
Возможно, ваше желание работать сверхурочно связано с тем, что вы чувствуете себя недостаточно эффективными. Задумайтесь, влияет ли на вас всеобщий культ продуктивности. Если вам больше нравится вечерами смотреть Netflix, а не кодить, можно не кодить. Но если уж начинать, то только для себя.
Совет #2: Пробуй новые технологии вширь, а не вглубь
Поговорим о широте и глубине познания. Чаще всего люди знают либо много, либо хорошо. Избыточная широта говорит о недостаточной глубине. Очень большая глубина говорит о том, что вы эксперт в конкретной технологии, но они имеют свойство выходить из моды.
Изучать область вширь — это нормально и важно, если вы хотите быть конкурентоспособными. Однако развивать широту, пока у вас нет глубины, — провальная стратегия. Если вы джун или миддл фронтендер, в первую очередь стоит сделать глубокое погружение во фронтенд. И даже если вы миддл+ и уже нарастили мышцы в своих стандартных инструментах, ничто не мешает задипдайвить в свою предметную область ещё раз.
Главное ограничение, как мне кажется, — оставаться в рамках веб-разработки. То есть стоит качать:
глубокие знания во фронте;
широкие знания во фронте;
широкие знания в бэкенде, инфраструктуре, CI/CD;
SEO.
Совет #3. Пробуй новые технологии отдельно друг от друга
Сферические кони в вакууме — это зло. И вот такой пет-проект именно им и является. А значит, он тоже зло.
Вместо этого я предлагаю делать пет-продукт. Он отличается от пет-проекта тем, что в нём отдельные задачи связываются в систему. Такой проект укладывает знания в чёткую структуру и помогает развиваться комплексно.
О том, как не сбиться с пути, поговорим дальше.
Совет #4. План не нужен, работай как работается
Раньше, начиная что-то делать, я не думал, какой результат хочу получить. Целью было попробовать свежеизученную технологию на абстрактной задаче, на этом всё.
Гораздо правильнее иметь роадмап.
Цель. Что хочется попробовать?
Когда мы начинаем пет-проект, всегда приходится балансировать между желанием узнать что-то новое и необходимостью сделать что-то функциональное.
Например, перед стартом своего самого свежего пет-проекта, опыт с которым и вдохновил меня на этот текст, мне были интересен Vite и хотелось запустить продукт в собственной инфраструктуре. К этому списку добавились PWA, веб-сокеты и SEO — всё это мне было интересно и в целом не выходило за компетенции веб-разработчика.
Идея. Какую функциональность интересно разработать?
Когда я начинал делать этот проект, ChatGPT был абсолютно везде. Последним триггером стало то, что мама спросила у меня, как им можно воспользоваться. Если он стал интересным даже для неё, значит спрос на эту технологию просто гигантский.
Идея моего пет-продукта — максимально простой доступ к ChatGPT.
Требования:
Простой интерфейс.
Минимальная функциональность: сделал запрос в API ChatGPT — получил ответ.
Авторизация через Telegram/VK.
Приём платежей через онлайн-кассу (мама, прости).
Архитектура и технический стек:
Здесь мы вновь сталкиваемся с дилеммой между «узнать» и «сделать».
Совет #5. Деприоритизируйте «узнать», главное — «сделать»
Зачем решать задачи, которые вам не хочется решать? Вы можете с минимумом усилий сделать себе API, хранилища, авторизацию.
Единственное, держите в уме Федеральный закон о персональных данных. Хранить данные пользователей РФ нельзя на серверах вне РФ.
Например, мой план выглядел вот так:
#1 | Написать сервер на Node.js | Умею |
#2 | В сервисе имплементировать restApi и WebSockets | Умею |
#3 | Завернуть свой сервис в Docker-контейнер и задеплоить его на арендованом сервере | Хочу научиться |
#4 | Написать фронтенд на React, используя Vite | Хочу попробовтаь новый фреймворк |
#5 | Обеспечить SЕО-оптимизация, в том числе, путем реализации SSR | Хочу научиться |
В инфраструктуре фронта я сильно разбираться не хотел, поэтому деплоить было решено через Vercel. С таким подходом я мог и попробовать то, что интересно, и получить крутой результат.
Это лишь примерный роадмап, он может отличаться в зависимости от уже упомянутого балансирования между «узнать» и «сделать».
Макеты и UI
Я не хотел прокачиваться в дизайнера и разбираться с Figma, поэтому нарисовал макеты на коленке. Коленкой стал Excalidraw.
Дальше я взял готовый UI Kit — Chakra UI. На этом этапе я приоритизировал «сделать» перед «узнать». У вас это может быть по-другому.
Бэкенд и инфра
Здесь я взял Node.js, Express, интегрировал ChatGPT, реализовал REST API для основных методов, а для работы непосредственно с чатом — имплементировал функциональность на web-сокетах.
Чтобы немного упростить взаимодействие с базой и не писать sql запросы и миграции к PostgreSQL, я взял Knex.js
Итак, я написал базовый REST API, прикрутил чат с веб-сокетами, закодил базовую jwt-авторизацию. А дальше…
Кажется, мы снова пришли к расфокусу. Или нет?
В принципе всё это не выходило за концепцию продукта, но задачи из блока инфраструктуры трансформировались, их стало сильно больше. Я крепко задумался, всё ли делаю правильно.
Совет #6. Никогда не советуйтесь с коллегами о пет-проектах
И тут меня осенило. У меня в компании так много крутых ребят, у которых гораздо больше опыта в тех сферах, куда я полез. Надо этим пользоваться! Я уверен, что надо общаться с коллегами, которые знают больше.
Кроме вашего окружения, вам могут серьёзно помочь туториалы с DigitalOcean.
Фронтенд
Итак, я наконец-то добрался до этапа, ради которого всё затеял. Я взял React за константу и выбрал react-query, чтобы комфортно работать с дата-слоем. Ну и Vite: вы же помните, что я хотел прокачаться, а мы ищем баланс между «узнать» и «сделать».
А дальше пет-продукт готов. ChatGPT принимает запрос, возвращает ответ. Прикрученные сторис, диалоги — всё как полагается.
Я много чего узнал и попробовал с этим пет-продуктом. Кажется, получилось прямо круто. Но, как говорится, есть нюанс.
Совет #7. Возьми за правило: сел за пет-проект, доведи до релиза в этот же день
На этом проекте я понял, что хороший пет-продукт точно не получится сделать за один раз. Я знаю, что вы, как и я, получаете мощный заряд дофамина каждый раз, когда релизите проект. Видеть результат всегда приятно, это заряжает мотивацией.
Слабая сторона подхода, который я описал в этой статье, в том, что пет-продукт — это не так уж весело в шортране. Зато один пет-проект, который вы ведёте с умом, стоит сотни мелких.
Придётся научиться делайте брейк-поинты и поддерживать мотивацию и радость в процессе. Подключили веб-сокеты — порадовались. Собрали что-то в Docker-образ — сходили в бар с друзьями. Написали UI — тоже отметили. Сделали тарифы/профиль/избранное/любую другую фичу — взяли отпуск и забили на продукт на полгода.
Вместо вывода
Перефразирую всё вышесказанного из ироничного в дружеское:
Кодить «после работы» — хорошо, но если только реально хочется
Ограничьте себя по направлению и стеку
Делайте «продукты», а не проекты
Следуйте роадмапу и делайте брейкпоинты
Общайтесь с теми, кто знает больше
Балансируйте между «узнать» и «сделать»
А ещё — получайте удовольствие! Потому что иначе всё это не имеет смысла.
Если душа требует написать «змейку» на Unity, напишите. Это мой финальный совет. Вредный он или нет — решать вам :)
Кстати, эта статья основана на докладе, который я собрал для Frontend Meetup от СберМаркета. Там больше шуток и философских разгонов. Если тема заинтересовала, можете глянуть ещё и его.
Tech-команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
