Как стать автором
Обновить
Купер
Кодим будущее доставки товаров

Pet-проекты — это зло. Вредные советы для фронтендеров

Время на прочтение6 мин
Количество просмотров19K

Привет, Хабр! Меня зовут Александр Водолазских. Я руковожу направлением разработки интерфейсов в СберМаркете и после работы люблю посидеть за кодом, разрабатывая собственные пет проекты.

Чего я только не кодил по вечерам — писал смарт-контракты на Solidity, копался с разными фреймворками и библиотеками, пилил своего убийцу Twitter на React.js... В моменты, когда фронтенд мне поднадоедал, я начинал писать сервисы на Node, Nest и даже на Go. А после — начал экспериментировать с мобильной разработкой на Swift.

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

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

Посмотрите, как здорово этот формат адаптируется под айтишку:

Оригинал Григория Остера VS моя версия для фронтендеров
Оригинал Григория Остера VS моя версия для фронтендеров

Совет #1. Зачем вообще нужны пет-проекты, если можно просто овертаймить

Есть время вечером? Так посидите над своим основным проектом. Менеджеры будут счастливы! А вы — сгорите.

Возможно, ваше желание работать сверхурочно связано с тем, что вы чувствуете себя недостаточно эффективными. Задумайтесь, влияет ли на вас всеобщий культ продуктивности. Если вам больше нравится вечерами смотреть Netflix, а не кодить, можно не кодить. Но если уж начинать, то только для себя.

Совет #2: Пробуй новые технологии вширь, а не вглубь

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

Изучать область вширь — это нормально и важно, если вы хотите быть конкурентоспособными. Однако развивать широту, пока у вас нет глубины, — провальная стратегия. Если вы джун или миддл фронтендер, в первую очередь стоит сделать глубокое погружение во фронтенд. И даже если вы миддл+ и уже нарастили мышцы в своих стандартных инструментах, ничто не мешает задипдайвить в свою предметную область ещё раз.

Главное ограничение, как мне кажется, — оставаться в рамках веб-разработки. То есть стоит качать:

  • глубокие знания во фронте;

  • широкие знания во фронте;

  • широкие знания в бэкенде, инфраструктуре, CI/CD;

  • SEO. 

Совет #3. Пробуй новые технологии отдельно друг от друга

Сферические кони в вакууме — это зло. И вот такой пет-проект именно им и является. А значит, он тоже зло.

Вместо этого я предлагаю делать пет-продукт. Он отличается от пет-проекта тем, что в нём отдельные задачи связываются в систему. Такой проект укладывает знания в чёткую структуру и помогает развиваться комплексно.

О том, как не сбиться с пути, поговорим дальше.

Совет #4. План не нужен, работай как работается

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

Гораздо правильнее иметь роадмап. 

Цель. Что хочется попробовать?

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

Например, перед стартом своего самого свежего пет-проекта, опыт с которым и вдохновил меня на этот текст, мне были интересен Vite и хотелось запустить продукт в собственной инфраструктуре. К этому списку добавились PWA, веб-сокеты и SEO — всё это мне было интересно и в целом не выходило за компетенции веб-разработчика.

Идея. Какую функциональность интересно разработать?

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

Идея моего пет-продукта — максимально простой доступ к ChatGPT.

Требования:

  1. Простой интерфейс.

  2. Минимальная функциональность: сделал запрос в API ChatGPT — получил ответ.

  3. Авторизация через Telegram/VK.

  4. Приём платежей через онлайн-кассу (мама, прости).

Архитектура и технический стек:

Здесь мы вновь сталкиваемся с дилеммой между «узнать» и «сделать».

Совет #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 — тоже отметили. Сделали тарифы/профиль/избранное/любую другую фичу — взяли отпуск и забили на продукт на полгода.

Вместо вывода

Перефразирую всё вышесказанного из ироничного в дружеское:

  1. Кодить «после работы» — хорошо, но если только реально хочется

  2. Ограничьте себя по направлению и стеку

  3. Делайте «продукты», а не проекты

  4. Следуйте роадмапу и делайте брейкпоинты

  5. Общайтесь с теми, кто знает больше

  6. Балансируйте между «узнать» и «сделать»

А ещё — получайте удовольствие! Потому что иначе всё это не имеет смысла.

Если душа требует написать «змейку» на Unity, напишите. Это мой финальный совет. Вредный он или нет — решать вам :) 


Кстати, эта статья основана на докладе, который я собрал для Frontend Meetup от СберМаркета. Там больше шуток и философских разгонов. Если тема заинтересовала, можете глянуть ещё и его.

Tech-команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на  YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.

Теги:
Хабы:
Всего голосов 30: ↑28 и ↓2+30
Комментарии23

Публикации

Информация

Сайт
kuper.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия
Представитель
Купер

Истории