Привет, Хабр! Я Женя Кучерявый, директор по фронтенду в 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 я составил простой план миграции:
Вырезаем старое.
Обновляем зависимости.
Переезжаем.
Задача понятная, но трудоёмкая, потому что вырезать нужно было много всего. Например, мы не хотели переезжать ещё и на Nuxt 3, потому что он в целом нам не нужен — система закрытая, SSR неоправдан.
Оценив план, CTO прикинул, что в целом это безопасный вариант, но потенциально бесконечный. Поэтому он предложил альтернативу — просто создать новый проект с скопипастить туда код, выкинув всё ненужное.
Я на такие вещи падкий. Мне говорят, что можно выкинуть старое и запилить новое — я соглашаюсь. Спойлер: зря.
И чтобы объяснить, почему же CTO вообще предложил такой вариант, нужно сделать несколько отступлений:
CTO удачливее меня. Например, мы вместе ныряли с аквалангами. Ему стало нехорошо, он показал жест инструктору и его подняли. А я в тот день чуть не умер (кулстори по запросу).
CTO трудоголик, которого лучше всего описывает его же цитата: «Наконец-то выходные, смогу нормально поработать». При оценке он просто помножил свою эффективность на количество человек в команде фронтенда.
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 минут, а не за час.
Чему мы научились
Всего три простых пункта:
Невовлечённые люди не должны влиять на планирование.
Декомпозируйте.
Работа с людьми эффективнее работы с кодом.
И всё?
Выводы какие-то на уровне джуниор-тимлида и из разряда «Делайте хорошо, а плохо не делайте».
Что же было на самом деле? И почему в других компаниях смогли переехать гораздо быстрее нас?
А ответ на самом деле очень простой — потому что мы совсем недавно были стартапом. А стартапы выживают за счёт такой практики как hero engineering — когда вы работаете на износ, чтобы закрыть любую проблему. Будь то упавший прод или нереалистичные сроки.
И тут у нас небольшой флэшбек:
Люди плохо справлялись, несмотря на мои усилия.
Но на самом деле всё было немного не так:
Люди работали недостаточно, чтобы закрыть переезд в срок.
И тут даже сложно этих людей винить. Не они согласовали сроки, не они затеяли такой длительный марафон, на котором hero engineering перестаёт работать, потому что все уже выдохлись.
И вообще это практика, которая очень сильно стреляет в ногу на длинной дистанции. Это как держать человека, который 24/7 вычерпывает воды из вашей лодки, хотя можно было просто заделать пробоину.
И это моя настоящая ошибка:
Геройствовать, чтобы скрыть косяки менеджмента.
Настоящий вывод
Комментарии (29)
onets
08.05.2024 22:21Как так вышло что из-за смены версии vue - сборка и деплой уменьшились на порядки? О чем вы не договариваете?
hello_my_name_is_dany
08.05.2024 22:21+2Автор указал, что был webpack, а стал vite. Никаких подводных камней.
kucheriavyi Автор
08.05.2024 22:21+3Всё верно, переехали на Vite и сборка стала быстрее.
Также у нас деплой включает в себя ещё и запуск тестов и выгрузку на сервер. Тут мы получили прирост за счёт:
Vitest, который в нащем случае быстрее Jest.
Удаления кучи зависимостей. Например, у нас была практика использовать пакеты, чтобы решать задачи, которые в одну строку решаются силами JS.
Удаления Nuxt. Теперь билд — это не приложение, которое нужно запускать, а просто статические файлы.
gmtd
08.05.2024 22:21Что-то не понял мораль сей басни. Вот это что ли?
Люди работали недостаточно, чтобы закрыть переезд в срок.
kucheriavyi Автор
08.05.2024 22:21+5Мораль вот тут:
Не будьте героем.
Когда человек геройствует на старете, то это хорошо, потому что иначе никак. Если запуск уже состоялся и позиции компании укрепились, что это моментально становится антипаттерном, потому что скрывает косяки менеджмента.
Тут нужна работа на два фронта:
Бизнесу сказать «Мы всё это время работали на 200%, но дальше так нельзя. Да, мы всё ещё можем быстро катить фичи, но фич будет меньше, потому что сразу после этого нужен рефактор/написание тестов. Иначе в будущем схлопнемся, потому что код станет write only».
Команде сказать «Я по выходным не работаю и вам не советую». Работать, конечно, можно, просто людям показывать нельзя.
gmtd
08.05.2024 22:21+1А мне кажется тут просто неопытность и инфантилизм главного героя (что подтверждают видосики)
Вариант 1. Оценить время и ресурсы перехода, проконсультироваться с парой профессионалов, которые такое уже делали, скорректировать сроки, умножить на полтора и предоложить план перехода бизнесу со всеми "за" и "против" (типа билд время Vite против Webpack и, следовательно, скорость работы)
Вариант 2. Постепенно переписывать всё время имея рабочую версию. Сперва на Vue 2.7. Убрать миксины, фильтры, все другое ненужное, затем постепенно переписать на Composition API. Убрать Vuex. Потом Vue 3 и обновление зависимостей. Потом Vite. Займёт дольше, но менеджмент не будет нервничать, и сроки будут плавающие
А "герой" / "не герой", работать на "200%" - это лирика какая-тоkucheriavyi Автор
08.05.2024 22:21+1Могу переименовать статью в «Чего мне стоило отказаться от изначального плана»
Dark_zarich
08.05.2024 22:21+1Я бы Vite сначала добавил, проще будет потом в дев режиме смотреть. Мигрировал своё приложение с вебпака на вит, без проблем с Vue 2 собиралось, а потом уже все остальное по вашему списку из варианта 2.
gun_dose
08.05.2024 22:21Уволить надо такого СТО. И вот, почему:
Во-первых, если работник работает больше 40 часов в неделю, это значит, что он не справляется с возложенными на него обязанностями. Соответственно, это либо просто плохой работник, либо он не соответствует должности.
Во-вторых, заниженные эстимэйты - это воровство у компании. СТО украл, а рассчитываться либо собственнику фирмы, оплачивая дополнительные часы работы, либо работникам путём переработок, либо и то, и другое вместе. И не надо думать, что это я преувеличиваю. Если из офиса, к примеру, украсть компы, для собственников это будет выглядеть точно так же.
kucheriavyi Автор
08.05.2024 22:21+1Удачи, CTO собственник.
UPD: CTO предложил вариант миграции, а не утвердил его — это уже моя заслуга.
gun_dose
08.05.2024 22:21Вот интересно, без переделки всего с нуля, насколько бы различалось время?
kucheriavyi Автор
08.05.2024 22:21+1It depends. Сценариев много: вырезать Nuxt/переехать на Nuxt3, сколько ресурсов на это кинуть и т.д.
По моим оценкам это бы заняло больше времени, но может столько же человекочасов. Ну и сложно спрогнозировать боевой дух, когда ты больше полугода сидишь на чемоданах.
gun_dose
08.05.2024 22:21Да, посмотрел мануал по миграции, жесть полная. Надо было на реакте делать))
GoodGod
08.05.2024 22:21+1Мы уже год переезжаем на Vue 3. Постранично, постепенно. Зато продуктовые задачи не останавливаем, просто берем по страничке в релиз.
kucheriavyi Автор
08.05.2024 22:21Поддерживаете две версии сразу или Vue3 просто лежит в сторонке и ждёт своей очереди?
Мы рассматривали Bridge, Module Federation или даже веб-компоненты, но решили не извращаться таким образом.
Продуктовые задачи тоже не замораживали — что-то новое появилось в проекте на Vue3, что-то добавляли в ещё не перенесённые страницы на Vue2. Просто объём сократился в разы.
GoodGod
08.05.2024 22:21+1Имеем 2 отдельных проекта. Отдельные URL обслуживаются старым проектом, отдельные URL обслуживаются новым проектом. Редиректы сделаны на стороне nginx + kubernetes. Т.е. у нас базовая единица разделения - отдельный URL.
Проблемы следующие: первый шаг очень большой, потому что нужно сделать один и тот же layout в старом и новом фронте, меню, модалки, панели, каркас и т.д.
Сложно мигрировать большие навороченные страницы со сложной логикой. Бывают такие страницы, которые мега навороченные по функционалу. Таких страниц у нас немного, остальные страницы в основном несложные мигрируются просто.
kucheriavyi Автор
08.05.2024 22:21А как шарите стейт?
GoodGod
08.05.2024 22:21+1У нас особого стейта нету. Пара примеров: количество непрочитанных уведомлений в нотификациях, пара восклицательных знаков в меню на разделах, на которые пользователю надо обратить внимание (документы просрачиваются например, надо загрузить новые).
Эти стейты загружаются отдельными API запросами. Т.е. при переходе на новый фронт полностью перезагружается весь фронт (полное обновление страницы), и делаются API запросы на получение всех необходимых "восклицательных знаков (стейтов), которые надо показать пользователю", и потом пока пользователь ходит по новому фронту стейты не загружаются, потом при переходе на старый фронт снова все загружается через API.
Данные страниц не кешируются. Т.е. если пользователь зашел в таблицу каких-то данных, то при очередном переходе на эту страницу данные загрузятся заново.
alexnozer
08.05.2024 22:21или даже веб-компоненты
Можно подробнее? Интересно, правда
kucheriavyi Автор
08.05.2024 22:21Вот тут хороший пример: https://www.youtube.com/watch?v=CaP5eAylYpI
ildarin
08.05.2024 22:21+1Да это самое планирование задач - вообще какой-то бич. Почему то, люди думают, что будущее возможно предсказать. На тему менеджмента и планирования. Однако забывают тот простой факт, что сама информация предсказания уже влиет на будущее.
Допустим, есть зеркало, которое предсказывает будущее. Вопрос: брать ли зонт? Если в зеркале ты мокрый - возьмешь зонт и будешь сухим. Если сухой - зонт не возьмешь и будешь мокрый. Парадокс. Проблема самореференции.
И начинается потом поиск виноватых - мол, кто же у нас "плохой"? Хотя виноваты вообще - все, даже я, ибо не сказал вам этого раньше. Мне импонирует позиция - валить все на менеджмент - их не жалко, но решение проблем через поиск виноватых - контрпродуктивно. Никогда еще тюрьма никого не исправляла, как и отрезание рук в Саудовской Аравии не излечивает бедность и воровство.
Тупо планирование процесса на вере в "периодичность" процессов дает сбой, ибо сама периодичность - мнимая. Сколько бы людей не умерли от голода, если бы предполагали возможность засухи, а не считали бы, что летом априори всегда идёт дождь?
И, мол, можно пусть не наверняка, но с какой то точностью дать прогноз. Но это именно, что - прогноз. Его точность всегда 50% - либо сбудется, либо - нет. Прогнозы можно давать лишь на 100% повторяющиеся процессы, причем точность выше, чем выше количество повторений. У Вас - оно всего теперь всего одно, вы один раз перешли с этого конкретного стека на другой конкретный. Теперь, вы можете планировать. И даже предполагать сроки. До этого - вы просто гадали. Да и теперь - периодичность будет мнимая, ибо одно повторение - не периодично, это лишь единичный случай, а не повторение. Я могу дать более-менее точный прогноз лишь на количество нажатий на кнопку за еденицу времни. И то - с предварительными расчетами. А там - может руку сведет, комп зависнет, палец устанет и т.д. Чтобы все факторы учитывать - нужна вся информация. А информации - бесконечно. Тогда, каким образом учесть точность прогноза (в процентах) если есть, допустим, лишь петабайт информации из бесконечного количества? Предел точности прогноза тогда всегда стремится к 0%, ибо c/∞=0
Лично я все равно буду геройствовать - мне это по фану. Мол, успею я за неделю сделать то, что невозможно сделать за неделю? Чисто челендж. Но да, это выматывает, тут уже вопросы здоровья - нужно следить за количеством отдыха и никогда не ставить зарабатывание денег другим людям (и даже себе) выше собственного здоровья. Но, к сожалению, основам здравоохранения, в том числе психического - ни в школах ни в спец/высших не учат.
Thomas_Hanniball
08.05.2024 22:21+2У вас проблема с целеполаганием и подменой целей.
Ваша цель "переехать с Vue2 на Vue3". Ещё раз повторю, изначально есть Vue2, а нужно Vue3. Всё, больше ничего.
Но вам было скучно, поэтому вы придумали себе дополнительные соревнования (челеджи), например, ограничили переезд количеством задач (120) и ограничили время (1 месяц). Из-за этих выдуманных ограничений вы загоняли себя и свою команду, занимались микроменеджментом, сами писали код, напрягали людей и остались по итогу ими недовольны. Не надо так.
Я всегда говорю коллегам:
1. Всем плевать на сроки. Если то, что вы делаете, важно для бизнеса, то бизнес всегда будет готов увеличивать сроки и затраты на этот проект. Если же это какая-то ерунда, то нет ничего плохого в том, что проект умрёт ещё на начальной стадии, когда станет ясно, что его долго или дорого делать. Правило 20 на 80 тут отлично подходит.
2. Когда проект закончен, всем плевать, уложился он в какие-то выдуманные сроки или нет. Через полгода об этом никто и не вспомнит. Всем важно итоговое качество. Если проект уложился в сроки, но качество его реализации г...вно, то вы получите клеймо г...внодела и текущее качество проекта будет напрямую связано с вашим именем. Г...вняные проекты - это плохой вариант для получения премий и продвижения в карьере.
3. Корректно определять сроки можно только для тех проектов, которые ранее уже выполнялись именно этой командой, т.е. когда известны все подводные камни и пути их обхода. Для новых и неизвестных проектов самый продуктивный вариант - это просто начинать делать работу, а не тратить время на попытки угадать сроки реализации. После 2-х недель активной работы будет понятно, какой примерно % проекта был сделан за это время. Это число экстраполируется до 100% проекта, а потом умножается на 2. Если итоговое время всех устраивает, то проект можно продолжать. Если все говорят, что это слишком долго, то либо урезаем объём проекта, либо просто его закрываем и перестаём тратить на него силы.
P.S. Когда-то давно я был таким же героем, как вы сейчас. Но теперь, имея за спиной десятки проектов, кучу прочитанных книг и несколько смен компаний, я перестал геройствовать, да и здоровье, убитое во время геройства, уже не позволяет повторять 12 часовые рабочие марафоны.
propell-ant
08.05.2024 22:21Вот п.3 на этом проекте не помог бы:
из 120 задач к концу первого месяца было сделано 80.
Значит за первые две недели было сделано примерно 40.
Примерно 20 задач в неделю. Получается, что под оставшиеся 80 задач нужно было просить еще (80 задач / 20 задач_в_неделю) * 2 = 8 недель = 2 месяца,
а общая длительность проекта была бы запланирована на 10 недель, чуть больше двух месяцев.
По факту проект занял еще вдвое больше времени.
antonblockchain
08.05.2024 22:21+1Мне когда я учился оценке сроков профессор сказал что умножать надо на Pi=3.14157
1) в два это мало
2) все будут думать что это хитрая формула, которую они не знали, и постесняются критиковать.
3) можно сказать что цель видна но пути реализации не прямые а кругами по этому Pipropell-ant
08.05.2024 22:21Если такой коэффициент видит ваш начальник, то он может и сообразить, что достоверность оценки трудоемкости обратно пропорциональна этому коэффициенту. То есть показывая 3.14 вы объявляете, что знаете о проекте чуть более 30% факторов, а всё остальное для вас темный лес.
Это может привести к некоторым сомнениям в компетентности оценивающего.
lytican
Добрый день. Вижу минус. Знакомая проблема, бро. В здоровом обществе за откровение автоматом плюс, но не тут же.
Я хотел бы услышать кулстори про то как правильно не умереть под водой. Поделитесь.
fromRozetked
"Хотя аппарат выдерживает сильное глубоководное давление, любой дефект в его форме или конструкции может стать фатальным — причем есть риск взрыва", — говорит ученый.
kucheriavyi Автор
Оборудование весит около 15кг, так кроме него вам ещё пихают грузила в карманы, чтобы компенсировать плавучесть самого комбенизона — он давольно сильно выталкивает наверх.
По какой-то причине в группе только у меня был электронный комплект датчиков, который ещё и пищал («Расслабься, он просто думает, что ты шестой раз погружаешься, а это вредно»). Ну ок.
Всё было нормально до глубины примерно в 5 метров, если не считать какого-то звука, похожего на моторчик. Я подумал, что это просто мимо лодка проплывают и остальные тоже его слышат (не слышали). После 5 метров резко похолодало и спустя буквально минуту я понял, что воздух не поступает. Я выплюнул шланг, перевернул выходом вниз и нажал на клапан — ноль эффекта.
Я подал жест инструктору, что меня нужно поднять, но он это проигнорировал или не заметил, потому что я замыкал группу. Нас предупредили, что всплывать самостоятельно это дважды плохая идея. Первая причина — сделать это со всем оборудованием очень сложно.
Так как жесты не помогли, я начал изо всех сил плыть наверх. Спустя минуту длиною вечность я сделал глоток воздуха, но радовался недолго, потому что вспомнил вторую причину — попытки удержаться на плаву просто вымотают тебя. Мне повезло, что там проплывали ребята, которые надули мне жилет (меня не проиструктировали, что так вообще можно) и дотащили до камней.
SystemOutPrintln
И тамада хороший, и конкурсы интересные...