Компания: МТС Веб-сервисы Позиция: Middle+ Frontend (Vue), 200–280K 💚 Продолжаем разбирать техничку и вопросы с интересных компаний на разные позиции, на этот раз взяли вопросы из первой части интервью Вопрос №1 Какой подход ты выбирал при миграции с Vue 2 на Vue 3? Слабый ответ: «Постепенно переписать всё на Vue 3 + TypeScript через Vue 2.7». Ответ технически корректный, но слишком общий. В нём нет главного: как именно шла миграция, почему был выбран такой путь и как контролировались риски. Сильный ответ: Я выбирал поэтапную миграцию. Обычно сначала выделяли участки с понятными границами: отдельные страницы, фичи или модули с минимальной связанностью с legacy-частью. Это позволяло мигрировать систему постепенно и не останавливать продуктовую разработку. На первом этапе выравнивали базу под миграцию: убирали самые проблемные места, снижали зависимость от mixins, выносили бизнес-логику из компонентов, наводили порядок в слоях данных и состояниях. После этого уже переводили части приложения на Composition API и TypeScript. Такой подход давал несколько преимуществ: — меньше риск сломать всё сразу — проще локализовать ошибки — можно катить изменения частями — команда продолжает поставлять фичи параллельно с миграцией В общем, “мигрировали итеративно, с контролем технического риска”. Что здесь реально проверяют: умеешь ли ты планировать сложные изменения, а не просто знаешь, что Vue 3 новее Vue 2. Вопрос №2 Какие архитектурные улучшения были в проекте и как они применялись — поверх или во время миграции? Слабый ответ: «По большей части во время миграции. С монолита на модульную архитектуру». Это не ошибка, но ответ слишком короткий. Он не раскрывает, что именно менялось в архитектуре и зачем. Сильный ответ: Архитектурные улучшения мы вносили именно во время миграции, потому что это лучший момент не только обновить стек, но и не перенести старые проблемы в новую версию приложения. Например, если система была слишком монолитной, то в процессе миграции мы начинали разрезать её на более понятные модули или доменные зоны: отдельно выделяли UI-слой, работу с данными, бизнес-логику, сторы, API-клиенты. Это снижало связанность и делало код предсказуемее. Также обычно пересматривали: — структуру модулей и границы ответственности — организацию состояния — слой работы с API — переиспользуемую логику — общие UI-примитивы и паттерны композиции То есть миграция была не отдельной задачей “обновить Vue”, а точкой входа для нормализации архитектуры. Что здесь реально проверяют: видишь ли ты миграцию как техническую операцию или как возможность улучшить устойчивость системы. Вопрос №3 Что ты считаешь важным знанием или навыком при работе с Vue? Слабый ответ: «Знание синтаксиса, новых фич, Teleport, Suspense, Composition API, composables, Vapor...» Проблема такого ответа в том, что это просто список терминов. Он не показывает, что ты понимаешь, зачем всё это нужно и как влияет на качество приложения. Сильный ответ: Для меня важно знать, например, как устроена реактивность и где у неё границы. Нужно понимать, когда состояние действительно отслеживается корректно, где можно случайно потерять реактивность, как не создавать лишние зависимости и почему это влияет на поведение интерфейса. Во-вторых, важно понимать композицию приложения: где должна жить бизнес-логика, что оставить в компоненте, что вынести в composable, а что вообще должно быть на уровне сервисов или data layer. Именно это отличает поддерживаемый проект от набора компонентов, которые “как-то работают”. В-третьих, важно понимать рендеринг и производительность: как работают обновления, что даёт правильная декомпозиция, где появляются лишние перерендеры, как влияют вычисления в шаблоне, watchers, асинхронные компоненты, lazy loading, SSR и hydration. И уже после этого идут сами фичи фреймворка: Composition API, Suspense, Teleport и экосистема вокруг Vue. Что здесь реально проверяют: понимаешь ли ты Vue как систему, а не как набор удобных хуков. ===================