При модернизации старой системы второй пилот сначала систематизирует доказательства

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

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

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

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

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

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

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