Не будьте героем

Привет, Хабр! Я Женя Кучерявый, директор по фронтенду в Rentu. В этой статье расскажу как мы переезжали с Vue2 на Vue3, какие шишки набили и чему научились. Статья не хардовая.

Начнём со стека, который у нас был:

• Vue 2.

• Nuxt 2.

• Vuex.

• Element-ui

• Bootstrap.

• Argon (шаблон для админки за 20$).

• amCharts 4 и 5.

• Плохие велосипеды.

• Jest.

• Webpack 4.

Стек как стек, хоть и староват. Но переехать всё равно хотелось и вот почему:

• Медленный код.

• Утечки памяти.

• Плохой DX.

• Легаси-технологии, на которые трудно нанимать людей.

• Проблемы с онбордингом.

• Долгие пайплайны — на деплой могло уходить 1-2 часа.

Всё бы ничего, но кроме причин у нас появился ещё и повод — 31.12.2023 прекращалась поддержка Vue2, что ещё сильнее усугубляло имеющиеся поводы.

Согласование

Обговорив всё это с CTO я составил простой план миграции:

1. Вырезаем старое.

2. Обновляем зависимости.

3. Переезжаем.

Задача понятная, но трудоёмкая, потому что вырезать нужно было много всего. Например, мы не хотели переезжать ещё и на Nuxt 3, потому что он в целом нам не нужен — система закрытая, SSR неоправдан.

Оценив план, CTO прикинул, что в целом это безопасный вариант, но потенциально бесконечный. Поэтому он предложил альтернативу — просто создать новый проект с скопипастить туда код, выкинув всё ненужное.

Я на такие вещи падкий. Мне говорят, что можно выкинуть старое и запилить новое — я соглашаюсь. Спойлер: зря.

И чтобы объяснить, почему же CTO вообще предложил такой вариант, нужно сделать несколько отступлений:

1. CTO удачливее меня. Например, мы вместе ныряли с аквалангами. Ему стало нехорошо, он показал жест инструктору и его подняли. А я в тот день чуть не умер (кулстори по запросу).

2. CTO трудоголик, которого лучше всего описывает его же цитата: «Наконец-то выходные, смогу нормально поработать». При оценке он просто помножил свою эффективность на количество человек в команде фронтенда.

3. CTO не трогал фронт больше года.

И это моя первая ошибка:

Проигнорировал красные флаги при планировании.

Но процесс уже был запущен

Я разбил переезд на 120 задач, завёл таблицу в вики, чтобы не дублировать компоненты и мы начали переезд. По изначальной оценке месяца должно было хватить.

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

Я же в это время осознал, что месяца нам мало:

• Люди долго возятся с задачами.

• Сложно проводить ревью.

• Какие-то компоненты дублируются, несмотря на таблицу.

И это моя вторая ошибка:

Слишком большие задачи.

Ничего не оставалось, кроме как декомпозировать их.

И вот спустя месяц я отчитываюсь, что мы закрыли 130 задач из 160.

Ещё месяц спустя закрытых задач уже было 160 из 200.

Не буду ходить вокруг да около и сразу скажу, что в итоге на переезд потратили 350 задач + ещё куча ушла на багфиксы.

Не справляемся

Тут я уже начал выгорать, потому что люди плохо справлялись, несмотря на мои усилия. Чтобы спасти положение я решил бросить все свои силы на это и тоже начал писать код:

И это моя третья ошибка:

Работал с кодом, когда нужно было работать с командой.

Переезд закончился

Несмотря на боль, выгоряние и растягивание сроков, мы всё же завершили переезд. Всего-то потребовалось 30 человеко-месяцев вместо 8.

Мы обзавелись новым стеком:

• Vue 3.

• Element plus.

• Bootstrap (в процессе выпила)

• amCharts 4 и 5 (почти всё на 5).

• Vite.

• Vitest.

• Велосипеды получше.

Показатели тоже значительно улучшились:

• Dev-сборка за секунду, а не за 2 минуты.

• Потребление памяти меньше в 2 раза.

• Улучшенный DX.

• Свежие версии зависимостей.

• Деплой за 7 минут, а не за час.

Чему мы научились

Всего три простых пункта:

1. Невовлечённые люди не должны влиять на планирование.

2. Декомпозируйте.

3. Работа с людьми эффективнее работы с кодом.

И всё?

Выводы какие-то на уровне джуниор-тимлида и из разряда «Делайте хорошо, а плохо не делайте».

Что же было на самом деле? И почему в других компаниях смогли переехать гораздо быстрее нас?

А ответ на самом деле очень простой — потому что мы совсем недавно были стартапом. А стартапы выживают за счёт такой практики как hero engineering — когда вы работаете на износ, чтобы закрыть любую проблему. Будь то упавший прод или нереалистичные сроки.

И тут у нас небольшой флэшбек:

Люди плохо справлялись, несмотря на мои усилия.

Но на самом деле всё было немного не так:

Люди работали недостаточно, чтобы закрыть переезд в срок.

И тут даже сложно этих людей винить. Не они согласовали сроки, не они затеяли такой длительный марафон, на котором hero engineering перестаёт работать, потому что все уже выдохлись.

И вообще это практика, которая очень сильно стреляет в ногу на длинной дистанции. Это как держать человека, который 24/7 вычерпывает воды из вашей лодки, хотя можно было просто заделать пробоину.

И это моя настоящая ошибка:

Геройствовать, чтобы скрыть косяки менеджмента.

Настоящий вывод

Не будьте героями!