Модернизация старого кода требует сначала археологии

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

Вот почему «археология» предшествует «трансформации». Сначала просмотрите файл сборки, затем зависимости, затем рабочую среду и затем тесты. Порядок не может быть отменен. build.xml все еще существует, но pom.xml не существует. Таких сигналов достаточно, чтобы указать на то, что проект живёт в эпоху Ant; можно ли скомпилировать код, можно ли запускать тесты и можно ли пересобрать продукт — вот первое свидетельство. Самая полезная часть модели здесь — не сразу писать новый код для старого кода, а выявлять эти свидетельства из кучи фрагментов.

Окружение также должно быть закреплено в первую очередь. Старый код часто поставляется со старыми JVM, старыми контейнерами и старыми архитектурными предположениями. Добавьте его прямо на современные машины, особенно в кросс-архитектурной среде, и при возникновении проблем легко добавить новый шум: действительно ли код поврежден по своей сути или проблемы вызывают эмуляция, зеркалирование и цепочки инструментов? Если на этом этапе не удастся добиться даже «один и тот же код может стабильно воспроизводиться в той же среде», все последующие действия по модернизации будут лишь догадками.

Ценность ИИ на этом этапе очевидна: он может помочь с переводом на уровне персонажа и структуры. Преобразование Ant в Gradle, преобразование старых сценариев сборки в теперь удобную для сопровождения форму, перемещение множества повторяющихся XML и шаблонов в более понятное место — все это хорошие кандидаты на то, чтобы оставить модели. Это быстро, хочется пробовать снова и снова и не так уж тривиально. Но для судейства это не подходит. Какие предупреждения можно держать в первую очередь, какие тесты на самом деле врут, какие модули следует отрезать в первую очередь, а какие классы только упаковывать и адаптировать. В конце концов, это все равно должны решать люди.

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

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