Фронтенд из трущоб

2021-10-13 13:03:22 Объясни простыми словами

Если вы хотите проверить Senior разработчика на прочность, попросите его объяснить что-то сложное простыми словами. На самом деле такая стратегия работает не только в программировании, а практически во всех сферах нашей жизни.

Всегда во время собеседования на позицию Senior и выше я задаю несколько вопросов и прошу ответить кандидата так, как бы он ответил на этот вопрос начинающему Junior’у. Один из самых попсовых вопросов это объяснить как работает функция reduce на массиве, и тут начинается... Один говорит что “функция reduce считает сумму элементов в массиве”, что лишь частный случай использования reduce, а другой отвечает что “функция reduce выполняет callback reducer записывая промежуточный value в аккумулятор передав начальное значение… бла бла бла”. У обоих ответов есть негативные последствия. В первом случае наш Junior уйдёт с ложными знаниями, а во втором случае он просто ничего не поймёт и подумает что дальше спрашивать особо нет смысла.

Другой пример это когда собираются 2 команды — бекенд и фронтенд, и начинают обсуждать какие-то breaking changes или совершенно новые фичи. Моя любимая часть начинается когда один из бекендщиков встаёт и заявляет: “Мы короче планируем прикрутить Redis в кубере, вы там по сокетам подключитесь и всё заработает, может воркер какой-нибудь еще понадобится, посмотрим”. На самом деле его предложение имеет смысл и прекрасно решит бизнес задачу, но он забывает учесть один факт. Скорее всего, многие из фронтенд команды понятия не имеют о чём он говорит. Да и часто на таких встречах присутствуют менеджеры, бизнес аналитики и другие ребята, для которых это вообще тёмный лес.

Если вы хотите узнать как нелегко сидеть на технических звонках НЕ техническим специалистам, предлагаю провести эксперимент. Просто включите эту трансляцию игры Дота 2 и послушайте комментаторов.

Здесь есть 3 состояния:
1) Вы играли в Дота 2 и полностью понимаете о чём речь (вы и есть тот бекендщик предлагающий прикрутить Redis)
2) Вы играли в League of Legends или Warcraft 3 и частично улавливаете знакомые слова (вы тот фронтендщик, который услышал только воркер и сокет)
3) Вы не играли в Дота 2 и похожие игры (вы тот самый ПМ, который ждёт когда же это всё закончится).

В этом всём есть одно большое НО, говорить сложным языком абсолютно нормально и даже правильно когда ты уверен что все понимают этот домен. Когда вы собрались фронтенд командой то можете смело предложить использовать декораторы для PropTypes во Vue 2, или переписать все сервисы на behaviorSubject в вашем новом приложении на Angular. Но как только в разговор включается PM, QA, бекенд команда — просьба сбавить обороты, котик Открыть/Комментировать

2021-08-31 12:59:00 Боль при работе с микрофронтендами

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

Самой большой болью при работе с архитектурой микрофронтендов является общий код. Как оказалось, если ты “разделываешь” свой большой монолитный проект на микрофронтенды, то замечаешь что абсолютно всё завязано на всём.

Store у всех приложений один, большое количество shared компонентов, да даже axios интерсепторы и синглтон с ролями пользователей шарятся между всеми страницами. А как насчет функций из папки “utils” которые фильтруют данные особым образом? Всё очень завязано, потому что с самого старта работы никто даже не думал про введение новой архитектуры. И весь этот общий код начинает плавно переезжать в отдельные репозитории, и здесь главное быть в адеквате и не перетрудиться.

Первым shared репозиторием стал наш ui-kit, или иначе библиотека компонентов. Во всех репозиториях мы использвовали Material UI, но над некоторыми его компонентами мы надстраивали свои еще более умные компоненты. К примеру у нас был не просто прогресс бар, а крутилка с прогрессом, логотипом компании и градиентной заливкой. И вот если в другом микрофронтенде тебе нужен этот компонент, то тебе нужно перенести его в репозиторий “companyName/ui-kit”, добавить документацию в storybook, закоммитить изменения, зарелизить новую версию библиотеки и залить её в npm. Нехило как для одного маленького компонента, правда?

Вторым shared репозиторием стала библиотека функций, которая содержала axios с его логикой получения и хранения токена, всяческие интерсепторы и другие utils функции. И здесь подход был такой же, переносим функции в отдельный репозиторий “companyName/utils”, добавляем документацию (если нужна), коммитим, релизим новую версию, заливаем в npm.

После того как новая версия готова, ты идешь в свой микрофронтенд и обновляешь этот пакет в package.json. Первые пара недель проходили именно в таком ритме, в постоянных релизах библиотек и головной боли. И пожалуй единственный момент который меня радовал это то что везде используется TypeScript. Поэтому нам не приходилось писать никакие typings чтобы понять какие аргументы принимает та или иная функция, или какого типа передавать props в shared компонент.

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

Я пошёл дальше воевать с новой архитектурой, и надеяться что у тебя на проекте всё более спокойно, котик Открыть/Комментировать

2021-07-30 12:59:00 Сумасшедшая архитектура, или как мы вводили микрофронтенды

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

Я сразу вспомнил про свой старый проект написанный на iFrame’ах, и сказать что это был прекрасный опыт я увы не могу. В то время iFrame был фундаментальным решением такого рода проблем, и в каком-то роде был монополистом. Хотим встроить реакт в ангуляр - юзаем iFrame, хотим подключить виджет с погодой - iFrame, и так далее. А ведь мы умудрялись даже строить архитектуру на этом, использовали postMessage API для коммуникации между приложениями, но всё это держалось на костылях которые могли развалиться в любую минуту.

Я сразу же решил отбросить мысли об iFrame и попробовал посмотреть что есть на рынке JavaScript на сегодняшний день. Во-первых для такого рода задач был введён специальный термин “микрофронтенд”, что пошло от всем известных “микросервисов” на бекенде. Во-вторых все эти подходы довольно современные и требуют большое количество фич из ES6, и поддержка в каких-то старых браузерах просто невозможна. В-третьих технология действительно еще сыровата, и можно наткнуться на множество невалидных статей и рекомендаций.

Когда нужно задуматься о введении архитектуры микрофронтендов?
- Если вы хотите чтоб над отдельными частями вашего приложения работала другая команда и ваш код не пересекался
- Если ваш репозиторий уже слишком жирный и вы сами начинаете в нём теряться
- Если ваше приложение пишется под нескольких кастомеров и у каждого свои “хотелки”
- Если вы хотите продавать фичи за дополнительную плату (к примеру страница аналитики с графиками за +5000$ в год)

После длительного инвестигейта мы остановились на Single SPA framework, который начали постепенно вводить для нашего проекта. Это была дорога боли и страданий, нерабочих решений и невалидных статей, но по итогу мы получили то к чему шли. За 15 рабочих дней (3 недели) нам удалось полностью уйти от монорепозитория и получить 4 отдельных репозитория, каждый из которых является самостоятельным приложением, которое может легко встроиться в другое с помощью роутера.

Далее мы обсудим какие проблемные места в современных микрофронтендах и на что нужно обратить внимание перед введением этой архитектуры.

Надеюсь ты еще не расплавился от такого жаркого лета, котик Открыть/Комментировать

2021-06-17 13:53:17 Emmet plugin или как писать HTML со скоростью света

Сейчас нам не приходится писать большие куски HTML кода как раньше… На смену длинному полотну из HTML тегов пришли компоненты, а на смену кастомным дропдаунам и таймпикерам пришли готовые решения. Сейчас мало кто решается на создание собственной системы компонентов с нуля, и чаще кастомизирует готовый UI Kit такой как Bootstrap или Material UI.

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

Мой подход к написанию разметки HTML полностью изменился когда мне показали плагин Emmet. Тогда это был отдельный пакет, который нужно было установить вручную, а сейчас это уже часть практически любой современной IDE, и работает по дефолту как только ты открыл свой редактор.

Написание разметки для меня это всегда что-то наподобие:

.container>.row>div.col-sm{test $}*3

Для быстрого теста можете вставить эту строку в любое место в вашем HTML и нажать Tab (для VSCode нужно включить эту опцию). Эта странная с первого взгляда строка превратится в солидный кусок HTML разметки:



Плагин и вправду позволяет ускорить вашу работу с HTML разметкой, но так же он умеет работать с CSS. К примеру mt20 превратится в margin-top: 20px;, а вот аббревиатура ovh превратится в overflow: hidden.

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

И напоследок, котик, не забывай использовать теги из HTML5, а то уже как бы 2021 год на дворе Открыть/Комментировать

2021-05-27 12:59:00 “Не нужно мне ваше ООП” (c)

Последние пару недель я провожу очередной найм на позицию Middle+ / Senior разработчика, и частенько такие серии собеседований меня разочаровывают. Ко мне приходят кандидаты, одни сильнее, вторые слабее, но объединяет их одно — “Я не работал с TypeScript”.

Причём да, я всегда беру во внимание что всё знать невозможно, и со многими технологиями нам просто не приходится встречаться в рамках своих проектов. Но в мире фронтенда под словом TypeScript также имеется в виду работал ли ты с ООП, и здесь мы наступаем на грабли.

Если человек никогда не работал с ООП то в 99% случаев это значит что он не разбирается в:
- Паттернах проектирования
- Структурах данных
- Абстракциях и наследовании

Когда мы говорим про Junior разработчиков, то их основная задача следовать правилам и всем best practices которые заведены на проекте, но когда мы говорим про позицию Middle+ и выше, то эти люди и будут устанавливать эти правила и best practices. На проектах использующих TypeScript и написанных в ООП стиле обязательно должен быть человек, который не падает в обморок при словах абстрактный класс и generics, который способен быстро набросать диаграмму классов и изучить .d.ts файлы для используемой библиотеки.

Хотим мы работать с TypeScript или нет это уже другой вопрос, но с каждым годом количество проектов на TypeScript стремительно растёт. За последние пару лет эта технология просто взлетела, и сейчас каждое второе предложение на рынке требует опыта работы с TS. Далеко ходить не нужно, еще ECMAScript 6 ввёл классы и нормальный синтаксис для наследования, а в ES2021 были предложены приватные поля, которые уже хорошо поддерживаются во многих браузерах. Эти фичи дают новый скачёк для JavaScript в сторону более зрелых объектно-ориентированных языков, и поверьте мне на слово — дальше будет больше.

Подведя черту, я считаю что для любого фронтенд разработчика знание ООП и умение понимать код на TypeScript это must have. А если в этом багаже знаний будут еще и паттерны проектирования — превосходно! Даже если вам и дальше будут попадаться проекты на чистом JS помните, что тот кто умеет писать на TypeScript может легко работать с нативным JS, а вот наоборот это не работает.

Котик, думаю самое время освежить свои знания в ООП Открыть/Комментировать

2021-05-13 12:59:00 Кошачий английский #5: Фразы на каждый день

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

Are you still around? - дословно переводится как “Ты всё еще здесь?”. Отлично работает когда вы не знаете работает ли еще человек, или уже ушёл домой (в наше время - закрыл ноутбук).

I really appreciate it / Awesome job, thanks a lot / That’s much, much better - фразы, которые помогут вам поблагодарить и похвалить человека, который выполнил для вас какую-то просьбу. Станет прекрасной заменой попсовому “thank you” так как имеет еще и эмоциональную составляющую.

The more …, the less … - американцы как и мы очень любят сравнивать как зависит полученный результат от начальных условий. Например “The more bugs we close, the less questions we’ll have on the demo”. Вместо more и less могут быть любые варианты сравнительных прилагательных - “The more memory we allocate to the Docker, the faster it can train the models”. Почитать больше тут.

My apologies, I have to jump off to another meeting - Быстро и вежливо сваливаем с митинга в Zoom и т.п.

Last but not least - переводится как “последнее, но не менее важное”. Американцы частенько говорят эту фразу когда доходят до последнего элемента в списке во время презентации, или давая свой фидбек. Вы тоже можете использовать это во время демо, когда доходите до последней фичи, которую собираетесь показать.

Тем временем длинные выходные позади, время возвращаться к работе. Кстати, как прошли майские праздники, котик? Открыть/Комментировать

2021-04-13 12:59:00 Я не умею писать регулярки

Мой путь в JavaScript начался с прочтения настоящей “библии” фронт-енд разработчика, а именно книги Девида Фленагана “Подробное руководство JavaScript”. На тот момент это было шестое издание, и с того времени много воды утекло. Когда сегодня меня спрашивают с чего начинать учить JavaScript и фронт-енд разработку я всегда теряюсь, поскольку всё что было актуально в моё время уже потеряло свою силу.

Помню как сейчас, одной из самых сложных тем на тот момент для меня были регулярные выражения. И хотя в книге этому была посвящена всего одна глава в 15 страниц, я старался перечитать её несколько раз. Не знающий программирования, я выписывал себе на листик все операторы и методы объекта RegExp, перечитывал и старался выучить наизусть.

Сейчас оглядываюсь назад и понимаю, что за весь мой опыт я практически никогда не использовал регулярные выражения на полную мощь. В частности, мне никогда не приходилось писать их с нуля, и на все “попсовые” задачи я всегда находил готовую и рабочую регулярку на StackOverflow.

Единственный валидный пример использования регулярок в моём коде, это был метод String.replace(). Когда мне нужно было заменить все вхождения в строке, мне приходилось закидывать первым аргументом регулярное выражение с флагом /g, для того чтобы заменить все совпадения. Думаю вам эта ситуация так же хорошо знакома:

“Bobby and Bob”.replace(/Bob/g, “Tob”); // result - “Tobby and Tob”

На днях я столкнулся со статьей про новые фичи ECMAScript 2021, и наконец это свершилось — мы получили новый метод String.replaceAll() заменяющий все совпадения строк. Метод довольно свежий, но уже нативно поддерживается всеми современными браузерами кроме IE. С выходом этого метода я говорю регулярным выражениям “до скорых встреч”, и возможно мы увидимся с ними на каком-нибудь специфичном проекте в будущем.

При этом, я не говорю что регулярные выражения бесполезны, и есть множество проектов где без них не обойтись (сложные парсеры файлов, WYSIWYG редакторы, подсветка синтаксиса кода). Но как по мне, то потратить это время на изучение основ Докера будет куда полезней, котик Открыть/Комментировать

2021-03-23 13:59:00 Нужно ли техническое образование фронтенд разработчику?

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

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

Да, ситуация и вправду вырожденная. Специфика моего проекта это machine learning, и как не крути ты должен иметь базовые понимания в области ML & AI. Вам может показаться что остальная работа фронтендщика это кнопочки да формочки, но поверьте и там иногда приходится вспоминать школьную программу (простой пример — отобразить линию, показывающую с помощью CSS градиента процент заполнения формы).

Программист это в первую очередь инженер, который решает задачи аналитическим путём. Зачастую все сложности и тонкости внутренней реализации скрыты от нас (прекрасные примеры это RxJS, D3.js, lodash), но поверьте мне на слово, это не будет продолжаться вечно. Каждый ваш прыжок вверх по карьерной лестнице будет вести в мир задач, у которых нету готовых решений. Тогда то и придётся прокачивать свои аналитические способности, другого выхода нет.

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

Я считаю что любой человек способен освоить любую профессию, главное — это найти дело, от которого ты получаешь удовольствие, котик Открыть/Комментировать

2021-03-05 13:59:00 Daily stand-up

Дейлики… Это же целая отличительная черта всего IT сообщества. Я постоянно слышу разговоры на кухне как кто-то не успел на дейлик, или сегодня дейлик отменили, или что какой-то Серёжа постоянно затягивает наши стенд-апы. До сих пор у меня ни разу не было проектов, на которых нет дейли митингов. Залетая на новый проект ты всегда спрашиваешь в какое время будут стенд-апы, подразумевая что без них проектов в принципе не существует.

Я посетил больше тысячи стенд-апов, и из проекта в проект я замечаю одни и те же проблемы. Когда ты Junior разработчик, твоя основная задача “отрепортил - и пошёл работать”, а вот когда ты на позиции Senior или Lead, твоя задача еще внимательно слушать то, что репортят другие. Ты должен быть максимально вовлечён в процесс разработки, и понимать кто, когда и зачем этим занимается. Ниже приведу плохие примеры репортинга, которые я настоятельно советую избегать:

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

Плохой пример: “Я продолжаю заниматься задачей, которую начал в понедельник”.
Хороший пример: “Я продолжаю заниматься добавлением новых фильтров для товаров на странице поиска”

2) Не ссылайтесь на встречи / созвоны, на которых не были все участники стенд-апа.

Плохой пример: “Я фиксил фидбек, который мне дал Джон вчера на нашем митинге”.
Хороший пример: “Я показал Джону свой пример страницы товара, он дал фидбек касательно добавления товара в корзину, и сегодня я планирую это переделать”

3) Старайтесь избегать общих терминов, давайте больше конкретики

Плохой пример: “Я продолжаю заниматься рефакторингом основных модулей”.
Хороший пример: “Вчера я занимался рефакторингом модуля платежей, а сегодня буду рефакторить модуль системы бонусов для Premium пользователей”

Надеюсь, что тебе не приходится сидеть и слушать “плохие примеры” на своих стенд-апах, котик Открыть/Комментировать

2021-02-15 13:58:48 Что делать если не сростаются отношения с заказчиком?

У меня было много разных заказчиков. Была и Европа, и Азия, и Америка, и Канада, не было пожалуй только Африки и Австралии. Я познакомился с огромным количеством умных и продвинутых людей, которые вдохновляли и критиковали, восхищались и огорчались, хвалили и ругали…

Пожалуй, этот пост будет касаться в первую очередь аутсорсинговых компаний, но вы можете это проэцировать на свои проекты. Вы знаете, что у нас в индустрии сильно ценятся soft скилы (помимо ваших умений мастерски справляться с задачами на React), и чем выше эти скилы — тем вы более востребованный специалист.

Как-то раз у меня прямо не сходились характеры с моим заказчиком. Вот от слова совсем. Я инициативный — он консерватор, я хочу подумать над оптимальным решением — он просит задачу на вчера, я хочу написать meeting minutes — он не хочет никакой документации. На этот момент я уже был на позиции Senior, и просто пойти сказать “ну не нравится мне с ним работать” было бы не совсем этично.

Чаще всего мне приходилось подстраиваться, находить правильные слова и приводить аргументы “за” и “против”. В какой-то момент мне казалось что на это уходит больше времени, чем хотелось, и я не понимал стоит ли это того. Тогда мой СЕО сказал мне такую фразу: “Ничего страшного, зато представь как прокачаешь коммуникацию”.

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

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

Но я надеюсь, что сейчас у тебя самый комфортный заказчик. А если нет — то это прекрасное время прокачать свои навыки, котик Открыть/Комментировать