Старые Perl-скрипты, которых никто не хочет касаться

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

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

Начните с выполнения, а не с дерева исходников

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

Проверьте каждый планировщик, способный запустить работу, а не только crontab текущего пользователя. Изучите системные каталоги cron, таймеры сервисов, пакетные планировщики, задания баз данных, системы непрерывной интеграции, панели управления и корпоративный планировщик, о котором забыли упомянуть специалисты по эксплуатации. На Unix-подобных серверах первый проход даст полезные зацепки, не создавая ложной уверенности:

ps -eo pid,lstart,args | grep '[p]erl'
find /etc/cron.d /etc/cron.daily /etc/cron.hourly -type f -exec grep -nH 'perl\|\.pl' {} \;
grep -R -n 'perl\|\.pl' /etc/systemd/system /usr/lib/systemd/system
find /opt /srv /usr/local -type f \( -name '*.pl' -o -name '*.pm' \) -print

Обычная строка процесса содержит PID, время запуска и полную команду. Аргументы важны, потому что часто они выбирают фактический бизнес-режим:

1842 Mon Aug 10 01:00:02 2026 /usr/bin/perl /opt/billing/bin/post.pl close

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

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

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

Граф вызовов выходит за пределы Perl

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

Сначала найдите буквальные ссылки и shebang, затем двигайтесь наружу от каждой подтвержденной точки входа:

grep -R -n 'use \|require \|do ' /opt/legacy-perl
grep -R -n '/opt/legacy-perl\|perl ' /opt /srv /usr/local/etc
find /opt/legacy-perl -type f -perm -u+x -exec head -n 1 {} \;

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

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

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

Воспроизведите интерпретатор до исправления кода

Поведение Perl зависит не только от файла .pl. До начала тестов зафиксируйте точный интерпретатор и параметры его сборки. /usr/bin/perl может отличаться от Perl в каталоге /opt, а обертка способна изменить PERL5LIB, локаль, часовой пояс или текущий каталог. Такие различия влияют на поиск модулей, разбор дат, сортировку и обработку текста.

Запустите следующие команды от имени продуктивного пользователя в рабочем каталоге продуктивной системы. Удалите секреты из сохраненного результата:

command -v perl
perl -v
perl -V
perl -e 'print join("\n", @INC), "\n"'
env | grep '^PERL\|^LANG\|^LC_\|^TZ'

perl -V сообщает, как собран интерпретатор, и показывает параметры, которые могут объяснить проблемы переносимости. Вывод @INC перечисляет каталоги, где Perl на самом деле ищет модули, в фактическом порядке. Сохраните оба результата вместе с реестром. Зависимость в частном каталоге приложения легко пропустить, если проверять только список пакетов операционной системы.

Проверка компиляции полезна, но правильно понимайте ее результат:

perl -c /opt/legacy-perl/bin/post.pl

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

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

Наблюдайте безопасно до добавления диагностики

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

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

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

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

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

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

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

Восстановление CPAN требует доказательств

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

Для каждой подтвержденной точки входа зафиксируйте пути загруженных модулей в безопасной тестовой среде:

perl -MData::Dumper -e 'END { print Dumper(\%INC) } do shift' /opt/legacy-perl/bin/post.pl

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

Сравните четыре источника: найденные в коде импорты, %INC из репрезентативных запусков, файлы в локальных каталогах библиотек и установленные дистрибутивы по данным исходного сервера. perldoc perllocal может содержать историю модулей, установленных инструментами CPAN, но системные пакеты и ручное копирование делают ее неполной. База пакетов операционной системы дает еще одну часть ответа. Ни один источник не должен быть единственным.

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

requires 'DBI', '1.643';
requires 'DateTime', '1.54';
requires 'Text::CSV_XS', '1.49';

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

Если старый выпуск больше не устанавливается, определите точную причину. Отсутствующий компилятор, недоступная библиотека C, удаленный дистрибутив, падающий тест и несовместимый с новым Perl код требуют разных решений. Не пытайтесь решить все пять проблем копированием старого каталога site_perl. В копии может оказаться бинарный модуль, собранный для другой ABI, и ошибка проявится только позже под нагрузкой. Архивируйте исходные дистрибутивы и исправления, когда это разрешает лицензия, но сделайте новую сборку воспроизводимой из объявленных входных данных.

Регулярные выражения исполняют бизнес-правила

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

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

Руководство perlre объясняет, что Perl сначала выбирает самое левое совпадение, а квантификаторы по умолчанию работают жадно. Это кажется основой, но становится бизнес-поведением, когда альтернативы пересекаются или захваченные значения участвуют в дальнейших расчетах. Последующая чистка с перестановкой альтернатив или добавлением якоря может изменить набор подходящих записей клиентов. Изменения Unicode и локали также способны повлиять на классы символов и регистр.

До рефакторинга превратите каждое значимое выражение в именованную таблицу примеров:

my @cases = (
    ['ACCT-001-EU',  'eu',       1],
    ['ACCT-001-US',  'domestic', 1],
    ['acct-001-eu',  undef,      0],
    ['ACCT-001-EU ', undef,      0],
);

for my $case (@cases) {
    my ($input, $class, $accepted) = @$case;
    my ($got) = $input =~ /\AACCT-\d{3}-(EU|US)\z/;
    my $ok = defined $got ? 1 : 0;
    die "acceptance changed for <$input>" if $ok != $accepted;
}

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

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

Фиксируйте поведение на границе системы

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

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

Небольшой стенд на shell может показать больше, чем неделя чтения и догадок:

case_dir=/tmp/perl-parity-case-01
mkdir -p "$case_dir"
cp fixtures/invoice.dat "$case_dir/input.dat"
cd "$case_dir" || exit 1
TZ=UTC LC_ALL=C /opt/oldperl/bin/perl /opt/app/run.pl input.dat >stdout.txt 2>stderr.txt
printf '%s\n' "$?" >exit-status.txt
find . -type f -print | sort >files.txt

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

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

Назначьте ответственных за реестр

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

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

Задайте четыре варианта и не выдавайте их за этапы одного процесса:

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

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

Сделайте неизвестное видимым

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

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

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

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

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

Выбирайте границу функции, а не файла

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

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

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

CodeHero читает все дерево с разными языками, переписывает Perl на Go, Rust или TypeScript и проверяет поведение стендом соответствия на записанном продуктивном трафике. Такой подход уместен лишь после сбора доказательств выполнения и граничных случаев. Автоматическое переписывание не восстановит квартальные входные данные, которые никто не записал, или решение оператора, которое существовало вне кода.

Первые десять рабочих дней должны уменьшить неопределенность

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

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

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

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