Перейти к содержанию
В рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVIВ рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVIВ рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVI
SmartyDevs
Модернизация · 01

Модернизация без переписывания.

Legacy-кодовые базы переплатформируются инкрементально — strangler-fig миграция, параллельная работа, без feature-freeze. Сделали достаточно таких проектов, чтобы знать, какие паттерны работают, а какие производят второе провальное переписывание подряд.

§ 01The problem

Какую проблему решаем

Большинство модернизаций legacy анонсируются как переписывание, идут два года, не шипают ничего пригодного и заканчиваются с исходной системой в продакшене. Мы не делаем переписывания. Мы strangle legacy сервис за сервисом, с параллельной работой, за feature flags, пока вы продолжаете шипать продукт. Legacy уходит в отставку, когда новый код заслужил трафик — а не когда план проекта говорит должен.

§ 02Capabilities

Что делаем

  • 01Strangler-fig миграция на уровнях кода, сервиса и данных
  • 02Anti-corruption слои между legacy и современными системами
  • 03Модернизация БД с dual-write и back-fill стратегиями
  • 04API-перевод между legacy и современными контрактами
  • 05Инкрементальный cutover за feature-flag'ами
  • 06Параллельная работа с consistency-сравнением
  • 07Тестовое покрытие, ретроактивно построенное вокруг legacy-поведения
  • 08Документация legacy-поведения — часто впервые
  • 09Честная оценка того, что можно модернизировать, а что должно уйти в отставку
§ 03Deliverables

Что получаете

  • Фазированный план миграции с риском и откатом на каждом шаге
  • Модернизированная система, работающая параллельно, пока не наберётся уверенность
  • Задокументированное legacy-поведение, которое ваша команда сможет защитить
  • План вывода legacy-системы из эксплуатации
§ 04Stack

Паттерны, которые используем

Strangler-fig pattern
Anti-corruption layer
Dual-write с верификацией консистентности
Event-driven миграция с CDC
Feature flags для cutover
Shadow-трафик и сравнение
Branch-by-abstraction
§ 05Ideal for

Подходит

  • Компаниям с кодовой базой 5+ лет, замедляющей каждое изменение
  • Командам, чья прошлая попытка переписывания провалилась
  • Инженерным лидерам, унаследовавшим legacy-системы, которые нельзя рисковать заменить
  • Компаниям под давлением acquisition модернизироваться
§ 06Process

Как идёт проект

  1. 01

    Карта legacy

    Документируем, что там реально лежит — поведение, интеграции, неявные контракты. Часто впервые записывается.

  2. 02

    План strangulation

    Какие слайсы мигрируют первыми, в каком порядке, с каким fallback. Письменный план подписан руководством.

  3. 03

    Миграция слайсами

    Сервис за сервисом, за feature-flag'ами, с параллельной работой, пока не наберётся уверенность.

  4. 04

    Вывод

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

§ 07Engagement

Как сотрудничать

01

Modernization Strategy

4 — 6 недель

Письменная оценка, целевая архитектура и фазированный план.

02

Modernization Programme

6 — 24 месяца

Фазированное выполнение рядом с вашей командой, квартальные этапы.

03

Surgical Modernization

8 — 16 недель

Одна конкретная подсистема извлечена и модернизирована.

§ 08Common questions

Frequently asked.

01Порекомендуете ли переписывание?

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

02Можем ли продолжать шипать продукт во время этого?

Да — в этом весь смысл strangler-fig. Никогда не нужен feature-freeze.

Есть задача, которую стоит решить как следует?

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

Начать разговор