Что должен знать начинающий Perl разработчик о перловой инфраструктуре

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

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

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

Также отмечу что весь свободный софт, и перл не исключение, делается для Unix-подобных ОС, на винде всё это можно делать, но не нужно, рекомендую сразу осваивать нормальную для девелопера ОС (GNU/Linux, FreeBSD).

Как обычно всё будет в шпаргалочном стиле, ссылки будут в основном на официальные доки, всяких док для быстрого старта полно в сети:

— Ньютон говорил что он увидел дальше, потому что стоял на плечах гигантов, имея ввиду Галилея и других. Таким образом Ньютон намекал разработчикам не писать, то что уже написано. А то что уже написано для перла обычно лежит на CPAN, ставить это можно как из репозитория вашего дистрибутива (но там обычно есть не всё), так и родной утилитой cpan и её вариациями cpanp, cpanm (+ полезная тулза cpan-outdated). Писать своё конечно можно, но только если текущие реализации чем-то не устраивают или хочется хорошо понять как это работает.
— И хотя о необходимости отладчика нет единого мнения, отладчик в перле есть, и желательно хотя бы минимально владеть им: perl -d имя_скрипта
— Померить производительность кода можно с помощью модуля Benchmark или Dumbbench, которой по мнению автора даёт более надёжные результаты.
— Найти узкие места можно с помощью профайлера Devel::NYTProf, на эту тему есть презентация (для поиска утечек памяти тоже есть модули, но не знаю какой сейчас правильный, вроде Devel::Leak)
— для модульного тестирования есть Test::More и mock модули типа Test::MockObject, ну и пара статей: про mock и нефункциональные тесты.
— Минимальный заголовок перлового скрипта/модуля

use strict;
use warnings;
use utf8;
use open (:utf8 :std);
use v5.16; # тут указать установленную версию: perl -v

Есть модули для того чтобы одной строкой подключить всё что нужно (Modern::Perl, uni::perl, common::sense), но они подключают разный набор модулей — мне например отключение undefined варнингов не подходит, но нет никакой проблемы сделать свой модуль.
— нужно понимать как перл работает с utf-8 (точнее хотя бы знать что не всё так просто) — дока, статья (в конце статьи ссылка на ещё одну статью)
— стоит знать и юзать хорошие практики и нарушать только понимая почему и зачем, утилита perlcritic может подсказать где отступили от «священного писания» (надеюсь не оскорбил никаких верующих)
— стиль кодирования это отдельная тема, за основу нужно брать этот документ. Утилита perltidy умеет приводить стиль кодирования к описанному в конфигурации = ей можно быстро причесать чей-то криво форматированный код.
— перл имеет достаточно удобную документацию, которой можно пользоваться и без коннекта к сети:

perldoc -f имя_функции
perldoc perlre
perldoc perlvar
и т.д.

Понятно что то же самое есть в красивом виде в сети: perldoc, для запоминания всяких особенностей возможно будет полезна такая шпаргалка, или расширенная шпаргалка и шпора по ссылкам, также всегда может помочь сообщество, в частности есть рассылка московских перловиков.
— создание модулей описано в документации, хотя думаю сейчас их чаще делают в ООП стиле, читать тут и тут, если не юзать тяжёлые модули, типа Moose, то грамотное ООП это use fields и Class::XSAccessor.
— интернационализация, стоит прочитать search.cpan.org/perldoc?Locale::Maketext::TPJ13
— документирование — POD
— свои модули разумно оформлять также как модули для CPAN (вполне вероятно что туда их и будете заливать), для упрощения это процедуры есть куча модулей типа ExtUtils::MakeMake и Module::Starter (ещё есть Dist::Zilla, но он без инсталлятора)
— Обработка исключений это eval (они имеет две формы, одна с аргументом-строкой это именно eval, а вторая с аргументом-кодом это уже больше try), есть неплохой вариант Try::Tiny.
— модуль Carp предоставляет аналоги warn и die со значительно более информативным выводом.
— Однострочки позволяют вам быстро сделать что-то небольшое, например проверить есть ли модуль в системе perl -E 'use SOAP::Lite'.
— вывести сложную структуру в лог/на экран можно модулем Data::Dumper, Data::Dump немного красивше + ещё есть DDP, JSON::XS много быстрее и больше подходит для маршалинга, но и для отладочного вывода можно использовать.
— неплохой формат для конфигов YAML, модуль YAML::XS.
— Бывает нужно понять от каких модулей зависит скрипт/модуль, тот могут пригодится модули типа Module::ScanDeps
— самый актуальный на данный момент web-framework Mojolicious, ещё есть Dancer, ну и Catalyst вроде жив.
— event loops & parallel programming — см. коммент от vividsnow
— валидировать параметры функции можно готовыми модулями, например Params::Validate, правда он не умеет валидировать сложные структуры, для этого можно юзать Data::Validate::Struct.
— для логгирования есть готовые модули, например Log::Log4perl, Log::Dispatch и универсальная обёртка над разными логгерами Log::Any.
— для разбора параметров командной строки есть модуль Getopt::Long.
— работа с базами данных DBI и ORM типа DBIx::Class.
— поиск абсолютного пути к скрипту из скрипта FindBin и lib::abs.
— Шаблонизаторы Template и Text::Xslate, в случае использования Mojolicious стоит пользовать его Mojo::Template (хотя его и отдельно можно пользовать).
— многие часто используемые функции есть в стандартных модулях, например для работы со списками есть List::Util и List::MoreUtils.
— IDE? настраивайте vim, emacs или любой иной продвинутый консольный редактор, не нужно монстров.
— базовая книга это «Programming Perl» Larry Wall, Tom Christiansen, Jon Orwant она же книга с верблюдом, если хочется понимать больше «Advanced Perl Programming» Sriram Srinivasan.

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

Конечно, как обычно, ожидаю помощи коллективного разума — устал уже вспоминать что ещё по крупному нужно, а в мелочи ударяться не хочется.

UDP: Благодарности человекам: UncleAndy, Андрей Ковбович, Pilat, Akzhan Abdulin,
полезный коммент от afiskon
ещё комент от biophreak
и ещё о шаблонизаторе, PSGI, про Test::More на русском, защиту исходников, документацию, стартовые доки.