Doomed to Wordpress

2020/04/01 frameworks vs diy

Мне всегда казалось, что для программиста не должно быть проблемой что-то запрограммировать. По крайней мере, поиск готового стороннего решения я всегда считал уместным в том случае, если существует решение, в точности решающее задачу. Если оно решает её не в точности, то, выбрав путь готового решения, приходится либо переформулировать задачу, что̀ мне кажется неверным путём, потому что следует исходить из цели, а не из ограниченности инструментария (либо, значит, цель не столь важна — но сто́ит ли тогда ею и заниматься?), либо переделывать найденное «готовое» решение, что предполагает затраты времени и сил на обучение его внутренней архитектуре, без знания которой модификации будут дилетантскими и рискованными, затруднение поддержки в будущем (в случае, если новые версии готового решения окажутся несовместимы с изменениями и опять потребуется всё переделывать), да и просто архитектура готового решения может не предполагать вмешательств, в этом случае понадобится замена решения и затраты времени и сил на поиск и внедрение нового. В общем, мне всегда казалось, что проще написать всё самому, ибо, повторюсь, для программиста это не должно составлять проблемы, ибо он на то и программист, чтоб программировать, а не гуглить.

Целый день писал тесты для сайта на Poet/Mason. Сразу скажу, что эту архитектуру для данного сайта выбрал я давно, сознательно и пока что не было случая, чтобы мне приходилось горько об этом жалеть. Конечно, сама идея шаблонизатора как некоего дополнительного недоязыка, который приходится осваивать разработчику и который требует особого интерпретатора, дурна и её следует избегать. Масон несколько оправдывается, во-первых, чрезвычайно удобной идеей объектно-ориентированных шаблонов (что̀, впрочем, некоторые считают как раз его недостатком; при этом я не рассматриваю всё объектно-ориентированное как благо, но в данном случае это прекрасный пример уместности ООП), во-вторых, минимальностью самого синтаксиса шаблонов: по сути, есть только маркеры, указывающие, интерпретировать ли данный код как perl или html, а всё остальное можно и не использовать. (Я говорю о Mason 2; судя по масоновской рассылке, до сих пор многие сидят упорно на Mason 1; тот куда больше похож на классический шаблонизатор или php, и я не понимаю этих людей.)

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

Начинается всё с того, что мне надо для тестов переопределить пару параметров в конфиге. С удивлением обнаруживаю, что возможность вручную выставить значение ($conf->set(...)) не предусмотрена! И сознательно, т.к. это, дескать, дурной тон, менять конфиги где попало. "Setting and resetting of configuration values will make it much more difficult to read and debug code!" Да, разумеется, особенно с таким синтаксисом, который всё же предусмотрен — с оговоркой, что исключительно для тестирования — чтобы временно поменять значение для данной лексической области видимости:

my $lex = $conf->set_local({key => 'value', ...});

В моём случае это сработало. Но, учитывая, сколь разными могут быть ситуации тестирования и специфику областей видимости в perl, тем более в Moose, не удивлюсь, если будет работать не всегда (например, когда придётся разбить код данных тестов на несколько модулей/функций, а общий код, содержащий как раз эти изменения конфига, вынести отдельно). Надо ли говорить, что если бы фрэймфорк писал я, не было бы такого ограничения. Когда я работаю с чужим кодом, возможность оперативно изменить значение из конфига в любом месте кода и быстро увидеть результат, вместо того чтобы городить отдельные тестовые конфиги или создавать их в памяти, требуется постоянно. (А тут кстати даже и создать конфиг нельзя, не прибегая к файлу. Конфиг почему-то всегда считывается из файлов, причём имена файлов хардкодные! Конечно, я могу переопределить класс конфига и всё это там сделать. В будущем я так и сделаю. Но на выяснение неизбежности этого весь день и ушёл. Дело осложнялось тем, что ряд параметров ещё и устанавливается в значения по умолчанию в других местах и через конфиг не переопределяется, хотя неработающий пример приведён в документации, но это уже можно считать багом. А если бы речь шла не о тестах, а о чём-то более срочном и важном?)

Мало того! И масоновский компонент нельзя создать на лету, поскольку иного способа его создания, кроме чтения из файла, не предусмотрено! Приходится городить кучу временных файлов. К чему объектноориентированность шаблонов, если такой шаблон, представленный в программе объектом, нельзя создать как любой другой объект?

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

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

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

permanent link