Зависимости в коде Perl

Question

Мне поручили забрать веб-приложение, написанное в каком-то старом коде Perl Legacy, и заставить его работать на нашем сервере, чтобы позже расширить его.Код был написан 10 лет назад отдельным разработчиком-самоучкой ...

В коде происходят странные вещи - они не боятся do lib-param.pl в первой строке, а затем в файле do /lib-pl/lib-param.pl - это другой файл.

Включая a.pl с методами b() и c() и более поздние версии, включая d.pl с методами c() и e(), также кажется довольно популярным ... Пакеты, похоже, неизвестны, поэтомуВы просто найдете & c () где-нибудь в коде позже.

Интересные вопросы:

• Есть ли инструмент, который может нарисовать отношения между perl-файлами?Показать список файлов, используемых каждым другим файлом?
• То же самое для баз данных и таблиц MySQL?Может ли он показать, какие схемы / таблицы используются какими файлами?
• Есть ли IDE, которая знает, какой c () вызывается - тот, что в a.pl или тот, что в d.pl?
• Как бы вы начали пытаться понять код?

Я склонен просматривать каждый файл и реорганизовывать его, но мне не разрешено это делать - только строгий минимум чтобы код работал.(Но так как код никогда не будет uses strict, я не знаю, собираюсь ли я ...)

Answer 1

Не использовать строгий - ошибка - не продолжайте. Переместите материал в d.pl в D.pm (или, возможно, лучше в целом), и, если код процедурный, используйте Sub::Exporter, чтобы вернуть эти подпрограммы обратно в вызывающий пакет. strict является лексическим, вы можете включить его только для одного пакета. Например, ваш новый package D;. Чтобы узнать, какой код вызывается, используйте Devel :: SimpleTrace.

perl -MDevel::SimpleTrace ./foo.pl

Теперь любые предупреждения будут сопровождаться полным бэк-логом - посыпьте предупреждения вокруг кода и запустите его.

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

Answer 2

Я бы написал утилиту для сканирования полного списка всех sub и того, в каком файле они живут; тогда я напишу утилиту, которая выдаст мне список всех вызовов функций и из какого они файла.

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

Во многих случаях, в хорошо написанном коде, этого будет достаточно, чтобы выручить меня ...