Как переписать личное портфолио с Angular 12 на Angular 22: разбор прыжка через десять версий

Портфолио на Angular 12, последние правки — годы назад. На работе при этом продакшен на Angular 19: плотные леджеры аудита грузовых перевозок, встроенные платёжные рельсы, кастомные монорепозитории. Разрыв между тем, что вы умеете, и тем, что показывает ваш домен, со временем только растёт.

Разница между «давно собирался» и «переписал» обычно не в свободном времени. Она в подходе: не тянуть десять миграций подряд, а один раз собрать всё заново на актуальной версии. Ниже — что именно меняется при переходе с 12 на 22, что стоит взять в карточки проектов и какие мелочи ломают вёрстку сильнее, чем кажется.

Что реально поменялось между 12 и 22

Angular 12 требовал церемоний даже для простых вещей: объявления NgModule, зонное отслеживание изменений с грязными проверками по всему дереву, подписки RxJS ради синхронного состояния компонента, структурные директивы *ngIf и *ngFor, рассыпанные по шаблонам.

Разница ощущается не в синтаксисе, а в том, сколько кода вы пишете ради самого кода. Angular 22 после 12 читается как другой фреймворк.

Чистая переписка против цепочки миграций

Десять версий через пошаговые апгрейды — это десять поводов оставить промежуточный костыль: совместимость со старым API, обёртки, «потом уберём». К моменту финиша вы получаете код, который формально на новой версии, но написан в логике старой.

Переписка с нуля даёт идиоматичные паттерны сразу: standalone-компоненты, сигналы, новый control flow. Платите за это временем и необходимостью заново собрать всё, что раньше работало.

Список из 30 логотипов ничего не говорит

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

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

• Платёжные потоки. Stripe Elements и Plaid Link для ACH и карточных платежей. Здесь дело не в том, чтобы отрисовать поле ввода: важно держать границы токенизации, обрабатывать асинхронные вебхуки и строить оптимистичные обновления состояния с корректным откатом при ошибке.
• Утечки состояния. Глобальные кэши легко сохраняют чувствительные платёжные токены при переходах между маршрутами. Переход на @ngrx/component-store с областью видимости маршрута привязал потоки оформления заказа к жизненному циклу компонента: расход памяти упал на 42%, устаревшее состояние сессии исчезло.

Деплой — часть работы фронтендера

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

Как это устроено: планирование спринтов и бэклог в Azure DevOps, репозитории, ревью пул-реквестов и триггеры деплоя в GitHub, роллинг-обновления без простоя с автоматическими проверками здоровья в Kubernetes. Выкатка кода и включение фич разведены через канареечные переключатели в Split.io и Harness. Grafana показывает время сборки пайплайна, состояние ingress и частоту клиентских ошибок.

Понимание того, как ваш бандл упаковывается в Docker, деплоится и мониторится, влияет на работу сильнее, чем ещё один освоенный фреймворк.

12 карточек навыков и SVG-математика

Сетку навыков собрали не как облако тегов, а как пары: Angular 19 и TypeScript, Signals и NgRx ComponentStore, RxJS и монорепозиторий Angular, токены Figma и Tailwind со SCSS, Stripe с Plaid плюс .NET и C#. Двенадцать карточек, инлайновые SVG для каждой.

Именно на иконках всё и посыпалось.

• Соотношение сторон. Иконка с координатной сеткой 256×384 внутри квадратного контейнера сжималась в узкую полоску. Помогло приведение всех иконок к единому боксу 256×256.
• Обрезка на HiDPI. У одного пути координаты выходили за границы viewBox — примерно треть волны молча отрезалась.
• Составные бренды. Stripe и Plaid в одной карточке потребовали ручных смещений и масштабирования, чтобы логотипы не наезжали друг на друга.

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

Продакшен на 19 и песочница на 22

В энтерпрайзе никто не переписывает критичные приложения в день выхода новой версии. Рабочие системы живут на Angular 19: предсказуемость и детерминированность там важнее свежих примитивов, особенно когда через них проходят финансовые потоки.

У личного сайта ограничений нет. Переписка на Angular 22 позволила сразу работать с последними примитивами сигналов и нулевым техническим долгом. Показывать оба уровня честно: это и есть умение держать стабильность в продакшене, продолжая экспериментировать на своём.

Чек-лист перед перепиской

1. Выпишите, что конкретно в старом коде мешает: сколько времени занимает правка, что невозможно добавить, где ломается вёрстка.
2. Решите, какая версия целевая. Если ограничений нет — берите актуальную, а не ту, до которой «легко доапгрейдиться».
3. Сначала перенесите контент и данные, потом код. Портфолио — про содержимое.
4. Опишите каждый проект по схеме: задача, решение, метрика, вывод. Метрика обязательна — хотя бы одна.
5. Прогоните адаптив и доступность на своём сайте так же строго, как на рабочем продукте: точки перелома, жизненный цикл компонентов, бюджет сборки.
6. Проверьте графику на границах viewBox и на HiDPI-экранах. Обрезка иконочных путей находится именно там.

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

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