Короткий ответ
#Что на самом деле означает легаси
- Легаси-система
- Система, поведение которой не понимает никто из доступных организации людей. Определяющее свойство — отсутствие вопроса, на который есть кому ответить, а не возраст технологии, состояние кода или версия фреймворка.
- Если проще Софт, от которого компания зависит и о котором ей не у кого спросить.
Это определение полезнее привычного тем, что показывает, что чинить. Если бы проблемой была старая технология, лечением была бы миграция. Если проблема в том, что некому отвечать на вопросы, то лечение — заставить отвечать саму систему, а это достижимо за дни, а не за кварталы.
Оно же объясняет то, что обычно сбивает с толку: новая система может быть легаси в день сдачи. Продукт, быстро собранный подрядчиками, которые затем ушли, обладает всеми свойствами легаси-системы с первого дня в продакшене. Как и система, собранная преимущественно кодовыми агентами, которую никто внимательно не читал, — см. Программа, написанная ИИ.
#Почему это кажется невозможным
Четыре конкретные трудности, и у каждой есть свой конкретный ответный ход.
| Трудность | Почему на ней встают | Ответный ход |
|---|---|---|
| Непонятно, с чего начинать | Каждый вопрос порождает три новых, и ни один не ощущается первым | Начинайте с описи, а не с поведения. Из чего это состоит — потом что с чем разговаривает |
| Неизвестное неизвестное | Нельзя перечислить то, о чём не подумал, а всё опасное лежит именно там | Выводите картину из системы, а не из разговора. На машину не действует то, что никто не упомянул |
| Негде безопасно экспериментировать | Понимать через изменения — естественный способ, и здесь он недоступен | Сначала статический анализ. Ничего не выполняется, значит, ничего не ломается |
| Никто не хочет это брать | Кто прикоснулся, тот и отвечает, поэтому все обходят стороной | Записанная и общая картина делает это активом компании, а не личной ответственностью одного человека |
#Порядок, который работает
-
Установите, что работает и где
До всякого кода: какие окружения существуют, что выложено в каждое, что запускается по расписанию и что работает вне репозитория вообще.
Последнее и ловит людей. Cron на сервере, функция, созданная в консоли, скрипт на ноутбуке, таблица, которую кто-то ведёт руками.
-
Соберите опись частей
Каждый компонент, с типом и внятным назначением. Это самый плоский из возможных результатов, и именно он делает возможным весь последующий разговор.
Это же и момент, когда большинство владельцев находят то, о существовании чего не знали.
-
Опишите внешние границы
От каких внешних сервисов это зависит? Что обращается к нему снаружи? На чьё имя оформлен каждый из них? Это зависимости, которые отказывают по чужому расписанию.
-
Пройдите по данным
Где лежат данные клиентов, как они туда попадают, куда уходят? Здесь пересекаются регуляторные обязанности, деловой риск и те части, которые нельзя ломать.
-
Запишите то, что установить не удалось
Явно и с приоритетами. Этот список и есть настоящий результат упражнения — а карта делает его достоверным.
-
Разберите список и только потом меняйте
Каждый закрытый вопрос — это небольшой возвращённый кусок контроля. Сделайте это до любой перестройки, и перестройка станет обычной инженерной задачей, а не актом веры.
#Что перестать делать
Читать код файл за файлом в надежде, что картина сложится.
Вместо этого Сначала выведите структуру, потом читайте выборочно. Месяц чтения даёт худшую карту, чем один анализ, и оставляет её в голове читателя, где ею никто больше не воспользуется.
Наводить порядок по ходу дела.
Вместо этого Не меняйте ничего, пока картины нет. Причёсывание кода, который вы не понимаете, — это способ сломать то, что работало, а подозрение на правку не падёт, потому что она «ничего не делала».
Ждать проекта по документации.
Вместо этого Проекты по документированию легаси почти никогда не заканчиваются: они безграничны, и никто не может сказать, сколько осталось. Выведенная картина ограничена и завершается.
Принимать комментарии и README за факты.
Вместо этого Считайте их заявлениями: записать стоит, но это не то же самое, что наблюдаемое поведение. README, описывающий систему по состоянию на 2021 год, не нейтрален — он активно вводит в заблуждение.
Решать вопрос о переписывании до того, как систему можно описать.
Вместо этого Сначала описание. Оно обычно меняет решение и всегда меняет оценку.
#Как найти рискованные части
Не вся легаси-система одинаково опасна, и знание о том, какие части опасны, — это большая часть пользы.
Четыре признака, и каждый виден из структурной картины, а не из чтения:
- Сосредоточенность. Один компонент, от которого зависят многие. Менять его дорого; не иметь возможности его менять — хуже.
- Скопление открытых вопросов. Шесть вопросов об одной подсистеме — это не то же самое, что шесть, распределённых равномерно. Скопление отмечает часть, которую никто никогда не понимал.
- Внешняя граница без подтверждённого поведения. Исходящая интеграция, у которой не удалось установить повторы, таймауты и обработку отказов, — это живой деловой риск, а не пункт технического долга.
- Расхождение между заявленным и наблюдаемым. Там, где документ или комментарий говорит одно, а код делает другое, чья-то картина мира уже неверна.
#Вопрос о переписывании
Кто-нибудь предложит переписать. Иногда это предложение верное. Почти никогда его нельзя оценить в момент, когда оно прозвучало, потому что аргумент за него обычно опирается на то же отсутствие понимания, которое и создало проблему.
Разговор меняют две вещи:
- Опись. «Переписать» означает разное, когда в системе шесть компонентов и когда их тридцать один, четыре из которых никто не может объяснить.
- Список открытых вопросов. Каждый нерешённый вопрос — это поведение, которое переписывание может молча потерять. Этот список и есть самый точный реестр рисков, какой может быть у предложения переписать, — и причина, по которой переписывания проваливаются.
Решение переписать, принятое после того, как есть и то и другое, — инженерное. Принятое раньше — ставка на чью-то память.
#Где 1ADK помогает, а где нет
Где помогает
- Структурная картина, выведенная, а не вспомненная.
- Открытые вопросы записаны и расставлены по важности, а не служат поводом для тревоги.
- Основания, чтобы новая команда могла проверять, а не верить.
- Расхождение между заявленным и наблюдаемым становится видимым.
- Запись того, что меняется, пока вы с этим работаете.
Где не помогает
- Объяснить, почему сделано именно так. Из кода этого не восстановит ничто.
- Сказать, переписывать ли. Он даёт исходные данные, а не решение.
- Оценить качество кода или найти уязвимости.
- Поведение во время работы — ничего не выполняется.
- Всё, что настроено только вне репозитория, — кроме отметки, что это неизвестно.
Вопросы, которые задают на самом деле
Возраст почти ни при чём. Система, написанная восемь месяцев назад подрядчиками, которых больше нет, — это легаси; пятнадцатилетняя система с тремя инженерами, которые в ней разбираются, — нет. Определяющее свойство одно: есть ли рядом кто-нибудь, кто может ответить на вопросы о ней.
Не раньше, чем вы сможете её описать. Почти каждое провалившееся переписывание начиналось до того, как кто-то установил, что существующая система на самом деле делает, — а теряются при этом всегда те части, о которых никто не помнил, что и есть исходная проблема.
Нет. Устройство и поведение — свойства кода, и их восстановит любой, у кого есть к нему доступ. Не восстанавливаются рассуждения. На практике это значит, что вы получите хорошую картину того, что система делает, и постоянный список решений, которые никто не может объяснить, — рабочее положение и гораздо лучше нынешнего.
Получить структурную картину — часы или дни. Дойти до состояния, когда команда спокойно меняет рискованные части, — месяцы. Ценность первого шага в том, что он показывает, какие части рискованные, вместо того чтобы выяснять это, изменив одну из них.