XP

Extreme Programming

Экстремальное программирование (Extreme Programming), часто обозначаемое аббревиатурой ХР, — это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продуктов, которая фокусирует усилия обеих сторон (программистов и бизнесменов) на общих, вполне достижимых целях. Команды, использующие ХР, производят качественное программное обеспечение с весьма большой скоростью.

Не в этой ли моде причина всеобщей болезни срывов заявленных сроков — Doom3, Half-Life2, NeedForSpeed Carbon? Не говоря уже об отечественной Lada Racing Club — у этих вообще продукт доводился уже после поступления в продажу.

Не могло это быть простым совпадением, что-то одновременно повлияло на монстров игрового рынка. Теперь понятно — «модная болезнь» XP ударила по связке «цена-время-качество», закона сохранения энергии ведь никто не отменял. Причем на Западе, где дорожат репутацией, пострадал критерий «время», а у нас — «качество». «Дорога в будущее» по Гейтсу — идеалисты верят в «новый подход», а реалисты за красивыми сентенциями прячут банальное «клиент потерпит». Между тем «наше все» — это все-таки Юникс и тот свободный софт, который пишут энтузиасты под лозунгом «Code is poetry». Наверное, во мне говорит дух индивидуализма. А еще — любовь к своему делу. И такой «экстрим» мне не по душе…

phpTAL

PHP Template Attribute Language

Одно из решений извечного вопроса web-разработки — «как разделять функциональный код, дизайн и наполнение?». Что делать это надо, вроде бы уже решили, а вот выбор того как это делать…

Подобно тому, как FastTemplate, написанный изначально на языке PERL, а потом перенесенный на PHP (одна из этих реализаций, кстати сказать, принадлежит мне), phpTAL является частью проекта ZOPE (однако, каково название), изначально написаного на языке Pyton, а потом вошел в состав пакета Smarty. В общем-то это не удивительно — технологии быстро становятся кросс-платформенными, а новые «инструментальные» продукты предпочитают предлагать разработчику уже известные технологии, а не каждый раз предлагать изучить что-то новое.

Преимущество phpTAL над FastTemplate декларируется в расширенных возможностях настройки шаблонов. Эти возможности предлагаются в виде специализированного языка программирования, на котором можно определять условия вывода того или иного блока, значение переменных, даже получение доступа к внешним данным. Да, поведение шаблона теперь можно определять достаточно подробно. И вроде бы все хорошо, но не отпускает смутное ощущение идиотизма ситуации…

Если нашей первоначальной целью было разделение кода от дизайна, чтобы дизайнер и программист независимо друг от друга могли работать над одним проектом «не пересекаясь», зачем снова все смешивать в «коктейль Молотова» и в сверстанном коде шаблона запрятывать дополнительную логику исполнения на дополнительном языке программирования? Зачем на ровном месте создавать еще одну технологию и стандарт, которую надо изучать, еще уровень проектирования, который усложняет разработку, еще один компонент системы, который снижает производительность и уже не может работать без «протезов» вроде кеширующей генерации кода и предопределенной обработки исключений, которая накладывает дополнительные ограничения на свободу действий программиста? Как же в таком случае принцип необходимого и достаточного, который в шутливой форме формулируется как KISS-принцип («Keep It Simple, Stupid» — «Делай проще, дурачок»)?

Когда-то я написал собственную реализацию Fast Template для php, когда используемая внешняя библиотека дала необъяснимый сбой. Функциональность ее была, конечно, весьма аскетичной и развивалась в основном «вглубь»,а не вширь — то есть путем оптимизации кода, а не расширения его функциональности. И было время, когда мне казалось, что внутри шаблона необходимо сделать какой-либо механизм, позволяющий тут же, «не отходя от кассы», определять поведение этого шаблона. И тогда мне это казалось правильным и необходимым. И вот мне предоставился случай увидеть свет в конце пути, крайнюю степень развития этой идеи. Сейчас она уже не кажется мне такой правильной и необходимой. Однажды разделенные, код и дизайн не должны снова смешиваться. Эту стадию «гремучих смесей» мы уже проходили…