Знания о старой системе после переписывания

Люди, которые понимают старую систему, не временная помеха на пути к более чистому коду. Они входят в действующую модель ее эксплуатации. При переписывании можно воспроизвести все видимые экраны, но без их знаний система сломается на первом необычном возврате, корректировке в конце квартала или перезапуске пакетного задания.

Не надо пытаться «скачать» содержимое чужой головы до того, как человек выйдет на пенсию. Утверждения о поведении системы следует превратить в доказательства, которые сможет проверить другой сотрудник: примеры, тесты, записи решений, рабочие инструкции и явно обозначенные неизвестные. Такая работа дает экспертам содержательную роль и после переключения. Относитесь к ним как к свидетелям и рецензентам, а не как к препятствиям или живым спецификациям.

Люди тоже входят в старую систему

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

Общее название «племенные знания» слишком расплывчато и потому бесполезно. Я разделяю их на четыре вида, для каждого из которых нужны свои доказательства:

• Бизнес-правила: какой результат организация хочет получить в конкретном случае.
• Наблюдаемое поведение: что действующая система делает на самом деле, включая дефекты, от которых зависят ее потребители.
• Рабочая практика: как люди планируют задания, восстанавливают работу, сверяют результаты и обходят решения системы.
• Историческое обоснование: почему существуют правило, таблица или обходной прием и что может сломаться после их удаления.

Эти категории часто противоречат друг другу. Эксперт может описывать утвержденное правило, хотя рабочая система следует старому исключению. У оператора бывает безопасная процедура восстановления, о которой не знает ни один разработчик. Финансовый руководитель может считать ошибкой расхождение при округлении, от которого зависит следующий отчет. Команда должна сохранять эти различия, пока ответственные лица не примут явное решение.

Поэтому схема подчинения плохо отражает распределение знаний. Самым осведомленным может оказаться специалист поддержки, который заранее знает, какие данные остановят ночное задание, или бывший разработчик, перешедший в эксплуатацию. Начинайте с событий, а не с должностей: кому звонят при сбое биллинга, кто утверждает сверку, кто понимает отклоненные записи и кто знает, почему до сих пор запускается якобы ненужный экспорт?

Люди тоже ошибаются. Их опыт заслуживает уважения, но воспоминание еще не доказательство. Знатоки старой системы предлагают гипотезы, примеры и контекст. Тесты и записи превращают эти сведения в основу, на которую может опереться миграция.

На интервью нужны случаи, а не экскурсии

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

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

На таких встречах я веду небольшой реестр утверждений. В каждой строке есть утверждение, источник, показательный пример, предложенная проверка, ответственный и уровень доверия. Например: «На приостановленный счет можно зачислить средства, но нельзя списать», источник сообщает руководитель отдела взыскания, приложены два идентификатора транзакций и предложен тест граничного условия. Другая строка: «После тайм-аута операторы перезапускают JOB17 с STEP30», источник сообщает ночной оператор, приложен журнал запуска, но тест восстановления еще не готов.

Уровень доверия не дает вежливому разговору превратиться в ложную уверенность. Используйте понятные отметки: подтверждено трафиком, подтверждено повторяемым тестом, подтверждено двумя людьми, единичное воспоминание и оспаривается. Доверие описывает качество доказательств, а не должность человека.

Задавайте неудобные уточняющие вопросы. Что вы делаете вне системы? Каким полям никогда не доверяете? Что проверяете перед утверждением результата? Какое сообщение об ошибке означает «попробуйте еще раз», хотя выглядит окончательным? Что произошло при последнем изменении этого правила? Кто не согласен с вашей версией? Так обнаруживаются теневые таблицы, телефонные согласования и компенсирующие меры, которых не видно при анализе кода.

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

Отделяйте намерение от совместимости

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

Для каждого существенного поведения запишите три ответа: что делает старая система, чего организация хочет после переписывания и чего ждут действующие потребители или отчеты. Затем выберите судьбу поведения. Сохранить означает, что новая система должна его повторить. Исправить означает намеренно изменить и утвердить новое ожидаемое значение. Удалить означает одновременно убрать поведение и его потребителей. Неизвестно означает, что переключение пока не может безопасно от него зависеть.

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

Нельзя прятать решение в запросе на слияние от разработчика. Финансовый отдел должен выбрать: сохранить результат, изменить интерфейс с главной книгой или ввести исправленное правило с обозначенной даты либо границы. После этого набор проверок паритета закрепит выбранный результат. Документация объяснит различие старого и нового результатов. Поддержка получит узнаваемый пример.

В книге Working Effectively with Legacy Code Майкл Физерс применяет тесты, чтобы взять действующее поведение под контроль до его изменения. Эта мысль относится не только к исходному коду. Характеризационный тест показывает, что происходит сейчас. Он не объявляет поведение правильным. Управление миграцией начинается там, где заканчивается характеризация: уполномоченный человек решает, что станет контрактом.

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

Превратите утверждения в исполняемые примеры

Знание сохраняется надолго, когда утверждение можно опровергнуть тестом. Текст по-прежнему нужен, но два читателя могут по-разному представить описанные в нем граничные условия.

По возможности пишите примеры на границе системы. Зафиксируйте минимальные входные данные, которые запускают правило, соответствующее начальное состояние, ожидаемый результат и допустимые побочные эффекты. Не проверяйте внутреннюю последовательность вызовов старой реализации. Такие тесты сохраняют структуру, а не поведение, и мешают честной модернизации.

Запись о поведении может быть достаточно простой, чтобы эксперт смог ее проверить:

{
  "case": "credit_on_suspended_account",
  "starting_state": {"status": "suspended", "balance": 12500},
  "input": {"type": "credit", "amount": 2500},
  "expected": {
    "accepted": true,
    "balance": 10000,
    "audit_code": "CR-SUSP"
  },
  "source": "collections_review_14"
}

У значений должны быть единицы и смысл. Если 12500 означает минимальные денежные единицы, укажите это в соглашении для тестовых данных. Если даты используют местный рабочий день, а не UTC, закрепите это условие. Многие предполагаемые расхождения паритета возникают из-за двусмысленных тестовых данных.

Стройте группы тестов вокруг границ, а не ограничивайтесь одним эталонным примером. Для правила о приостановленном счете проверьте зачисление, списание, нулевую и максимальную допустимую сумму, смену статуса во время обработки и повтор того же запроса. Эксперт часто знает, какие случаи уже вызывали проблемы. Инженер знает, где могут проявиться границы реализации. В наборе нужны оба взгляда.

Если результаты различаются, отдельно запишите старый и утвержденный варианты. Полезный стенд может возвращать MATCH, APPROVED_DIFFERENCE, UNEXPLAINED_DIFFERENCE или NOT_COMPARABLE. Двоичный результат «пройдено» или «не пройдено» подталкивает команду утверждать необъясненные изменения ради зеленого индикатора.

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

У производственного трафика есть слепые зоны

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

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

Чтобы трафик стал стабильным тестовым набором, ему нужен контекст. Скрывайте или заменяйте токенами чувствительные значения, сохраняя связи между ними. Фиксируйте справочные данные, которые иначе изменятся между запусками. Записывайте допущения о времени, локали, порядке и ответах зависимых систем. Сохраняйте исходный идентификатор записи, чтобы расследовать сбой без копирования производственных данных в заявку.

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

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

Наконец, выделите карантин для случаев, которые пока нельзя сравнить. Сообщение может вызывать недоступного партнера, зависеть от просроченных справочных данных или запускать необратимое действие. Для каждого такого случая нужны ответственный и причина. Если команда просто удалит их из набора, неопределенность исчезнет из отчета, но останется в системе.

Документация должна объяснять решения

Хорошая документация миграции сообщает следующему инженеру, что обещает система, где это обещание проверяется и почему существует исключение. Каталог экранов и таблиц устаревает еще до переключения, потому что описывает старую форму, а не новый контракт.

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

Записи решений особенно нужны там, где паритет нарушен намеренно. Укажите старое и выбранное поведение, затронутых потребителей, утвердивших решение людей, условие выпуска и сигнал для отката. Не пишите расплывчатое «исправлена ошибка расчета». Назовите точное различие: «Новый счет один раз округляет общую сумму; адаптер главной книги добавляет балансирующую строку для счетов, созданных до даты правила».

Рабочие инструкции требуют той же точности. Указание «перезапустите пакет при зависании» опасно. Опишите, как оператор определяет зависание, какая контрольная точка безопасна, какие повторные побочные эффекты проверить, какая сверка подтверждает завершение и когда передавать проблему дальше. По возможности сделайте безопасные предварительные условия автоматическими проверками. Если автоматизация только изображает уверенность, явно оставьте решение человеку.

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

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

Проверяйте документацию выполнением задачи. Дайте сбойный случай инженеру, который не участвовал в миграции, и попросите объяснить ожидаемый результат, найти тест и определить путь восстановления. Его затруднение указывает на дефект документации с воспроизводимым примером.

Эксперты не должны превращаться в очередь

Экспертам по старой системе нужны реальные полномочия при переписывании, но ожидание одного человека по каждому вопросу заменяет скрытые знания видимым узким местом. Протокол проверки должен направлять их внимание на неоднозначность и риск.

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

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

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

Официально выделите время. Проверка миграции поверх полной рабочей нагрузки уступит следующему инциденту, и это правильно. Руководители должны снять другие обязанности, запланировать окна решений и учитывать утверждения без ответа как риски поставки. Не измеряйте участие посещением встреч. Считайте закрытые утверждения, утвержденные примеры, объясненные различия и показанные процедуры восстановления.

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

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

Разногласие указывает на риск

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

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

Например, один оператор говорит, что отклоненный платеж можно безопасно повторить, а другой предупреждает о дубликатах. Их процедуры могут различаться потому, что одна очередь назначает токен идемпотентности, а старый канал этого не делает. Общий тест «повтор безопасен» скрыл бы точную границу, которую должна обеспечить новая система.

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

Молчание тоже служит доказательством. Область без уверенного владельца, свежего трафика и повторяемого примера требует более тщательной проверки. Команды часто называют ее неиспользуемой, потому что удаление упрощает план. До удаления проверьте планировщики, журналы доступа, созданные файлы, последующие импорты и календарные процедуры. Если доказательств мало, изолируйте функцию за элементом управления переключением и отслеживайте спрос, не изображая уверенность.

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

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

Без эксперта нужен другой метод

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

Начните со следов решений. Заявки об инцидентах показывают, какие сбои имели значение и кто участвовал. Запросы на изменение объясняют появление условия. Журналы пакетов и календари планировщика раскрывают зависимую от времени работу. Файлы сверки показывают, что другой отдел считал достоверным. Шаблоны поддержки содержат повторяющиеся ошибки. История кода может назвать рецензентов модуля, даже если его автор ушел.

По этим следам составьте карту свидетелей. Каждый может знать узкую границу: бухгалтер получает экспорт, партнерская команда отправляет файл, специалист поддержки узнает дубликаты, инженер инфраструктуры восстанавливал последний сбойный запуск. Спрашивайте только о событиях, с которыми человек работал сам. Несколько узких показаний безопаснее одного заимствованного общего рассказа.

Если это безопасно, исследуйте старую систему экспериментально. Клонируйте похожее на производственное состояние в изолированную среду, меняйте по одному входному значению и записывайте результаты с побочными эффектами. Начните со случаев из журналов, затем исследуйте границы в ветвлениях, таблицах проверки и обработке ошибок. Никогда не проводите исследовательские транзакции в действующих финансовых, промышленных или клиентских процессах только из-за слабой документации.

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

Выбирайте элементы управления переключением по оставшейся неопределенности. Плохо понятый отчет можно параллельно запускать для заданных бизнес-событий. Для редкой необратимой транзакции может потребоваться ручное одобрение и путь отката. Якобы ненужный экспорт можно изолировать и отслеживать до его календарного запуска. Такие меры требуют времени, но честно показывают цену неопределенности.

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

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

Переключение меняет работу, но не потребность в суждении

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

Определите переход до переключения. Перечислите регулярные обязанности: утверждение исключений, сверка результатов, обновление справочных данных, перезапуск работы, объяснение отчетов и разбор дефектов. Назовите нового владельца, вспомогательный материал, дату демонстрации и условие выхода старого эксперта. Фраза «знания переданы» не подходит. Подходит условие «новый владелец сервиса выполнил две показательные сверки и восстановил сбойный пакет во время репетиции».

Проводите рабочие репетиции с реалистичными сбоями. Отключите зависимость, добавьте дубликат сообщения, сделайте справочные данные просроченными и вызовите частичную обработку пакета. Новые владельцы должны диагностировать проблему и восстановить работу с помощью новых средств наблюдения и инструкций, пока прежний эксперт смотрит. Каждая подсказка после этого превращается в недостающую проверку или инструкцию.

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

Храните старую среду и доказательства по юридическим, рабочим требованиям и правилам обращения с данными. Команде может понадобиться воспроизвести спорный результат или объяснить историческую транзакцию. Это не означает, что неподдерживаемую систему надо навсегда оставить подключенной. Определите доступ, изоляцию, срок хранения данных и право запуска.

Последняя проверка состоит в отсутствии. Могут ли новые владельцы провести закрытие периода, восстановиться после сбоя, ответить поддержке и изменить документированное правило, пока прежний эксперт недоступен? Если нет, найдите недостающее доказательство и повторите репетицию.

Переписывание успешно, когда организация может объяснить поведение без фольклора и изменить его без вызова одного конкретного человека. Люди, которые поддерживали старую систему, заслуживают большего, чем формальное интервью. Дайте им точные случаи для оценки, запишите обнаруженные разногласия и сделайте их знания исполняемыми. Новая команда получит доказательства вместо историй, а эксперты оставят после себя не вечное дежурство, а работающую основу.