kamyshev.code
2.18K subscribers
40 photos
565 links
Архитектура, код, софт-скиллы и всё остальное. Вопросы, пожелания, комментарии — @igorkamyshev

https://kamyshev.me
Download Telegram
История: когда нужно пожертвовать скоростью ради простоты

Я написал систему, довольно простую по сути. У пользователя есть задачки, он может двигать их по разным статусам. Кроме этого, в системе было предусмотрено много дополнительной функциональности — синхронизация задачек с Трелло, уведомления о смене статуса через электронные писема и СМС, etc.

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

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

В итоге, я просто переписал этот кусок кода, и теперь пользователь ждет пока выполнятся все дополнительные штуки. Ответ занимает 1 секунду.

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

#кейс #проектирование
История: удаленная база и две минуты страха

В 2017 году я работал над генератором интернет-магазинов. И тогда я еще хуже представлял себе как правильно обращаься с данными.

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

Тематическая статья — Версионная миграция структуры базы данных: основные подходы

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

#кейс #данные
Давно не рассказывал о факапах, которые случались со мной.

Два года назад я сходил на митап и послушал доклад про redux-symbiote. Меня очень вдохновила эта идея — писать ревьюсеры и экшон-креаторы всегда бесило, а тут вужх, и все готово.

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

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

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

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

#кейс
​​Бонус. У этой библиотеки были проблемы с выведением типов, я решил что смогу легко их решить и переписал библиотечку, немного изменив API. Эта версия использовалась еще в одном проекте, что принесло еще больше боли — две версии странной технологии с разными API. Не делайте так, пожалуйста.

#кейс
В начале этого года мне перелетела удивительная задачка. Нужно было построить умный валидатор excel-таблиц. Макеты выглядели примерно так: пользователь грузит файл и в окошке видит список ошибок — имя ячейки и текст ошибки.

Было смутное ощущение, что пользоваться этим будет сложно, но кто поймёт этих корпоратов. Задачку на окошко с ошибками взял мой коллега, но вместо окошка он предложил писать ошибки прямо в документ. Это стоило примерно ничего (файл мы все равно перезаписывали для других нужд), но сильно упрощало жизнь пользователям. Им больше не нужно было сравнивать ошибки из интерфейса с данными из документа.

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

#кейс #softskills
Массово выкидываем старый код

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

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

Вообще, наша глобальная цель — сделать так, чтобы в репозитории не было кода, которые не «видят» пользователи. Думаю, это достойная цель для любого проекта.

#кейс #рефакторинг
Одержимость тестированием

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

В Самокате у нас был примерно такой флоу релиза:
+ планируем версию, накидываем таски, которые в неё попадут;
+ каждая таска проходит через QA;
+ когда все таски сделаны, собираем контейнер версии, которую собираемся релизить;
+ QA делают регрессионное тестирование;
+ катим в продакшн;
+ QA делают смоук-тест.

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

В Aviasales все устроено совсем иначе. Разработчик делает таску, другой разработчик ее тестирует и заодно смотрит код, после — катим таску на продакшн, потом ещё 10 минут смотрим за фоном ошибок и метриками.

В такой парадигме код доставляется клиентам сильно быстрее. А самое удивительное, что и багов больше не стало. Мне подход «смелых релизов» нравится больше.

#кейс #тестирование
Цели мы сформулировали в формате «мы верим, что так должно быть».

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

Но есть участки кода, которые совсем устарели. Например, у нас осталось немного кода на CoffeeScript. Поддерживать и развивать это нет никаких сил — мы считаем это легаси и при первой возможности выкидываем или переписываем.

В эту категорию могут попасть не только кусочки кода, но и целые продукты. Например, «Карта низких цен» устарела и технически и продуктово. Сейчас она законсервирована — не развивается, не поддерживается, просто доживает свой срок.

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

Мы пишем новый код в новом месте, и контролируем консистентность подходов автоматическими проверками — пишем кастомные правила для линтеров, которые проверяют, что все пользуются платформой одинаково.

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

#кейс
Третья цель — удачные технические решения переиспользуются. Тут все просто — писать что-то еще раз всегда (почти) дольше и дороже, чем взять готовое.

Мы делаем кучу внутренних библиотек: UI-кит, штука для работы с аналитическими событиями, небольшая тулза для работы с куками и несколько других. В них сконцентрирован не только код, но и подходы, которые мы рекомендуем использовать продуктовым командам.

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

#кейс
Продолжим историю про цели фронтенд-департамента Авиасейлс 🤗

Четвёртая цель ближе всего к людям — мы хотим использовать классные современные технологии.

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

> Например, один проект мы собираем через Gulp и вроде все хорошо, но gulp-sass не поддерживает кастомные имплементации sass. А node-sass умер и хотелось бы заменить его на dart-sass. Это причина, почему нам придётся отказаться от Gulp, хоть он и решает все наши задачи отлично.

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

#кейс
Закончу историю про цели нашего фронтенд-департамента 🤓

В Авиасейлс у нас много маленьких продуктовых команд. То есть, в каждой команде есть свои фронтендеры, бекендеры, QA, мобильные разработчики, аналитики, вот эвер. Соотвественно, получается много разных команд, которые взаимодействуют между собой через общую кодовую базу.

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

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

Может показаться, что мы придумали микрофронтенды, но это не совсем так. Дело в том, что сейчас вся эта система имеет две особенности:
+ все отношения определяются статически, еще при сборке бандлов известно какие виджеты присутствуют на странице и как они связаны между собой;
+ все виджеты и отношения деплоятся одновременно и приезжают на клиент в одном бандле.

Вероятно, в будущем мы будем развивать эту систему и придём к более трушным микрофронтендам 🤷‍♂️

#кейс
Пару месяцев назад ко мне пришли ребята из небольшого стартапа и попросили помочь нанять им фронтенд-разработчика.

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

Дополнительную сложность добавляла специфика компании — крипто-стартап. Это отпугивало кучу перспективных кандидатов. Но в итоге все прошло отлично — мы начали работать 18 февраля, провели 8 технических интервью, 15 марта сделали оффер классному чуваку, а 6 апреля он вышел на работу.

Завтра расскажу как это было.

#кейс
18 февраля я начал работать с крипто-стартапом. За месяц поисков потратил 10 часов времени, внизу на картинке подробности.

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

#кейс

Дальше давайте продолжим в формате вопросов-ответов, пишите в комментарии 👇
Закончил работать с ещё одним крипто-стартапом. Они подросли и им понадобился фронт-лид, который бы взял на себя управление довольно большой командой (11 инженеров). Мы работали над этим наймом две недели — 22 апреля впервые созвонились, а позавчера ребята наняли чувака по моей рекомендации.

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

#кейс

Если вам нужно нанять фронтендера, а собеседовать его некому — пишите 🤗

@igorkamyshev
Теперь заметка про неудачный пет-проект доступна публично 🚀

Неудачный проект: Checkmoney

Я пока не понимаю, насколько такой формат постов уместен, так что, пишите фидбек, пожалуйста.

#кейс
Запись сварилась 😱

Вчера я ходил на публичное собеседование по систем-дизайну на TechLead Crew. Моё первое «бекендерское» интервью. Хоть я его и провалил, все равно считаю опыт успешным.

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

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

#проектирование #собеседования #кейс

Пишите ощущения в комментарии 👇