Рок-н-ролл мертв, а Perl еще нет

Никогда не предполагал, что окажусь в шкуре Perl-программиста - но это случилось. На новом месте (региональная сеть NGN/IMS) мне досталась в наследство куча перлового кода (предбиллинг, управление подключениями, устройствами, услугами) и полтора программиста, способные значительным усилием воли его читать, а в крайнем случае даже править. Автора этого безобразия большей части кода я уже не застал, хотя до того успел пообщаться с ним, находять по другую сторону баррикад и подключая Asterisk/CallWeaver и FreeSWITCH к операторскому оборудованию.

Конечно, я надеялся все переписать все на Java/Groovy, однако вовремя остановился - это оказалось слишком дорого и больно. В итоге мы остановились на Perl и это позволило:

• Постепенно переписывать работающий код по частям и повторно использовать некоторый унаследованный код после минимального рефакторинга
• Не переучивать коллег - разве что более осознанно подойти к coding conventions

Пришлось, правда, переучиваться самому - плевался поначалу, но втянулся.

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

#!/usr/bin/perl

package MyModule;

sub calculate {
  ...
}

calculate(@ARGV) unless caller();

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

Но чаще модули не запускаются вручную сменным инженером или кроном, а собираются в более крупные единицы:

• Юниксовые демоны, написанные с использованием Proc::Daemon (Net::Daemon оказался слишком умным) и запускаемые инит-скриптом в стиле SysV (никаких новомодных systemd)
• Web-приложения, использующие PSGI согласно последней моде

Последние можно разрабатывать разными способами:

• Опираясь исключительно на спецификацию - в этом случае разбор URL, параметров и заголовков, возвращение требуемого Content-Type, шаблонизация и многое другое становятся проблемами самого разработчика
• Используя Plack - эталонную реализацию спецификации, которая предлагает стандартизованный способ декомпозиции приложений (в т.ч. выделения Middleware и специального DSL для настройки и склеивания разных приложений в одно), также обросла кучей разных полезных плагинов
• Используя один из полноценных web-фреймворков, хотя на самом деле их, похоже, всего лишь 2 - Dancer и Mojolicious

Я бы рассмотрел всерьез первый или второй вариант, а также запуск приложения под управлением какой-нибудь минимальной реализации на С вроде uwsgi (она приглянулась мне больше evpsgi, патча для nginx и модуля для Apache), если бы у нас были серьезные требования к производительности. Однако к web-интерфейсу не предполагалось публичного доступа, зато требования к простоте разработки очень даже предъявлялись. В итоге был выбран Mojolicious и скорее по иррациональным соображениям - в нашей местности обитают люди, которые очень его любят.

Сейчас весь старый код работает на последнем оставшемся сервере с Slakware 12.2.0 (который поначалу было едва справлялся с нагрузкой а сейчас почти отдыхает) и потихоньку переползает на новые сервера с ALT Linux. В последнем пришлось обновить Mojolicious, Plack и Starman, который используется в качестве самостоятельного web-сервера без всяких фронтендов типа nginx и тем более apache. Я также опакетил evpsgi и начал было перепиливать сборку uwsgi, однако быстро потерял к ним интерес - поэтому до репозитария они не добрались.