В связи с тем что дефицит кадров в ИТ отрасли велик, а перловиков совсем мало (а те что есть уже хотят быть техдирами и получать много денег) многие конторы с радостью берут способную молодёжь для превращения в перловиков.
Компания в которой я сейчас работаю тоже об этом задумалась и я вспомнил свою идею набросать некую шпаргалку-карту для начинающих шеф-поваров по приготовлению перловой каши.
Сразу хотелось бы отмести разговоры о смерти перла, вроде где-то тут не помню кто писал, что если технология перестала быть модной и кажется мёртвой, то это означает, что технология зрелая, понятна её область применения и нужно идти и работать, а не трещать языками.
Perl 6 считаю другим языком и его долгое и мучительно рождение не мешает жить и развиваться перлу.
Конечно бывает что технологии умирают, однако если посмотреть на даты в истории коммитов в репозитории перла и даты в ленте заливки/обновления дополнительных модулей, то не скажешь что перл зачах — жизнь кипит ежедневно. Как-то я специально мониторил модули на CPAN — десятки модулей обновляются/заливаются ежедневно.
Также отмечу что весь свободный софт, и перл не исключение, делается для Unix-подобных ОС, на винде всё это можно делать, но не нужно, рекомендую сразу осваивать нормальную для девелопера ОС (GNU/Linux, FreeBSD).
Как обычно всё будет в шпаргалочном стиле, ссылки будут в основном на официальные доки, всяких док для быстрого старта полно в сети:
— Ньютон говорил что он увидел дальше, потому что стоял на плечах гигантов, имея ввиду Галилея и других. Таким образом Ньютон намекал разработчикам не писать, то что уже написано. А то что уже написано для перла обычно лежит на CPAN, ставить это можно как из репозитория вашего дистрибутива (но там обычно есть не всё), так и родной утилитой cpan и её вариациями cpanp, cpanm. Писать своё конечно можно, но только если текущие реализации чем-то не устраивают или хочется хорошо понять как это работает.
— И хотя о необходимости отладчика нет единого мнения, отладчик в перле есть, и желательно хотя бы минимально владеть им: perl -d имя_скрипта
— Померить производительность кода можно с помощью модуля Devel::NYTProf, на эту тему есть презентация (для поиска утечек памяти тоже есть модули, но не знаю какой сейчас правильный)
— для модульного тестирования есть Test::More и mock модули типа Test::MockObject, ну и пара статей: про mock и нефункциональные тесты.
— Минимальный заголовок перлового скрипта/модуля
use strict;
use warnings;
use utf8;
use open (:utf8 :std);
use v5.16;
Есть модули для того чтобы одной строкой подключить всё что нужно (Modern::Perl, uni::perl, common::sense), но они подключают разный набор модулей — мне например отключение undefined варнингов не подходит, но нет никакой проблемы сделать свой модуль.
— нужно понимать как перл работает с utf-8 (точнее хотя бы знать что не всё так просто) — дока, статья (в конце статьи ссылка на ещё одну статью)
— стоит знать и юзать хорошие практики и нарушать только понимая почему и зачем, утилита perlcritic может подсказать где отступили от «священного писания» (надеюсь не оскорбил никаких верующих)
— стиль кодирования это отдельная тема, за основу нужно брать этот документ. Утилита perltidy умеет приводить стиль кодирования к описанному в конфигурации = ей можно быстро причесать чей-то криво форматированный код.
— перл имеет достаточно удобную документацию, которой можно пользоваться и без коннекта к сети:
perldoc -f имя_функции
perldoc perlre
perldoc perlvar
и т.д.
Понятно что то же самое есть в красивом виде в сети: perldoc, для запоминания всяких особенностей возможно будет полезна такая шпаргалка, или расширенная шпаргалка и шпора по ссылкам, также всегда может помочь сообщество, в частности есть рассылка московских перловиков.
— создание модулей описано в документации, хотя думаю сейчас их чаще делают в ООП стиле, читать тут и тут.
— документирование — 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 немного красивше, JSON::XS много быстрее и больше подходит для маршалинга, но и для отладочного вывода можно использовать.
— неплохой формат для конфигов YAML, модуль YAML::XS.
— Бывает нужно понять от каких модулей зависит скрипт/модуль, тот могут пригодится модули типа Module::ScanDeps
— самый актуальный на данный момент web-framework Mojolicious.
— валидировать параметры функции можно готовыми модулями, например Params::Validate.
— для логгирования есть готовые модули, например Log::Log4perl, Log::Dispatch и универсальная обёртка над разными логгерами Log::Any.
— для разбора параметров командной строки есть модуль Getopt::Long.
— IDE? настраивайте vim, emacs или любой иной продвинутый консольный редактор, не нужно монстров.
— базовая книга это «Programming Perl» Larry Wall, Tom Christiansen, Jon Orwant она же книга с верблюдом, если хочется понимать больше «Advanced Perl Programming» Sriram Srinivasan.
Про понятные названия, разумные размеры функций и т.п. тоже нужно говорить, но это не привязано к перлу и уже много раз сказано, посему не здесь.
Конечно, как обычно, ожидаю помощи коллективного разума — устал уже вспоминать что ещё по крупному нужно, а в мелочи ударяться не хочется.
Автор: worldmind
