13 апреля 2011 в 01:21

Эти бесчисленные парадигмы, концепции, инструменты и фреймворки из песочницы

Мое мировоззрение, как программиста, сформировалось еще во времена консольных приложений и текстовых пользовательских интерфейсов, на смену им пришли графические оконные GUI, а сейчас я наблюдаю уже третий виток технологий, связанный с глобальной сетью. Каждый раз, конечно же, приходилось менять не только любимый язык программирования, но и весь технологический стек, с наработками, заготовками и достаточно обширными библиотеками, кои сейчас гордо зовутся фреймворками. Резать приходилось по живому, нещадно и решительно.

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

Наблюдая за становлением третьего, на моей памяти, поколения технологий и специалистов, могу отметить, что повторяются как “велосипеды”, так и “грабли”. Именно поэтому, я не мог не написать этой статьи. Имея большой соблазн, спуститься в самую конкретику и разобрать по винтикам несколько современных языков и технологий, их связки и особенности стыковки, но оставим это для других статей и сконцентрируемся на принципах, остающихся неизменными во всех инкарнациях информационных систем. Каждый из принципов я поясню на нескольких примерах, уже привязанных к вебу.

1. Не нужно измышлять хитростей там, где можно сделать просто.

1.1. Например, не стесняйтесь отказаться от ООП там, где старое доброе процедурное программирование быстрее и эффективнее. Разворачивать классы и объекты в памяти имеет смысл в таких задачах, когда инстанс приложения будет жить хоть какое-то продолжительное время. А когда скрипт запускается чтобы за доли секунды отдать ресурс, то разветвленные концептуальные классы совсем ни к чему. В конце концов, выдача ресурсов веб-сервером, это нечто сродни stdout, выданный кусок уже не изменить. Хотя, в серверных задачах, как демоны, пакетная и отложенная обработка, кравлеры, вычисления и т.д., ООП конечно же нужен.

1.2. Кто сказал, что для наследования и переопределения, обязательно нужны объекты? Вполне подойдет иерархическая файловая структура или иерархические запросы к базе.

1.3. Если Вас беспокоит, что код выглядит не круто, а даже совсем просто, но поставленную задачу все ровно выполняет, то стоит пересмотреть свои представления о программировании. Совсем не обязательно в одном проекте применить все известные паттерны и концепции.

1.4. Общественное помешательство на шаблонизаторах мне не вполне понятно, ведь большинство скриптовых веб-языков сами являются шаблонизаторами. Самый яркий пример – это PHP: переменные подставляет, циклы и ветвление есть, а главное, что все это не требует дополнительного парсинга шаблонов. При внедрении акселераторов, шаблоны будут прекомпилироваться в байт-код так же, как и все другие части программы.

1.5. Сейчас многие руководствуются принципом “скачать из интернета и прикрутить”, но даже если времени мало, то хоть просмотрите скачанный код, возможно, это натолкнет на мысль, как то же самое сделать более просто. Ведь нет ни какой гарантии, что автор скачанного кода имел больше опыта, таланта и времени, чем Вы. Ну и конечно же, если Вы относитесь серьезно к системе, которую пишете, то должны знать, понимать и чувствовать каждую строку кода в ней.

2. Выберите и зафиксируйте инструментарий на продолжительное время, если хотите разнообразия в функционале.

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

3. Неуместное и не адекватное использования инструментов встречается чаще, чем плохие инструменты.

У каждого языка и технологии есть круг задач, для которых он подходит как нельзя лучше, а для других задач наверняка есть свои адекватные средства решения.

4. Невозможно и не нужно отделять данные, логику и представление на одном слое абстракции.

Это удивительно, но еще до изобретения MVC, и уж тем более, до его массового внедрения программисты понимали, что в каждом модуле всегда есть три части: логика, данные и отображение (или код, структуры памяти и интерфейс). Но вот в последнее время я наблюдаю злоупотребление этим принципом, мол “сказали разделять, то мы и разделим”. А разделять не всегда и получится. Даже если выделить слой представления (отображения), то в нем всегда найдется место всем трем частям: логике отображения, данным отображения и шаблонам отображения. Поэтому делить можно вечно, а Змей Горыныч, все равно будет о трех головах. Та же ситуация и с выделением модели и контроллера, в них опять можно будет выделить все три компоненты. Упорная борьба с этим фактом приводит многих к порождению неимоверного количества кода, классов, конструкций и примочек. Я не говорю, что MVC не работает, просто не нужно его использовать так фанатично, повсеместно и энергично. Помните, борьба с проблемой может только ее усугубить, не лучше ли принять и даже использовать этот факт. В конце концов, правильное понимание вопроса породило такие классы систем как СУБД, сервера приложений и GUI. Заметьте, в формулировке я написал именно “на одном слое абстракции”. Поясню: СУБД оперирует и данными и логикой и отображением на уровне реляционной абстракции (или же других информационных моделей), сервер приложений оперирует на уровне абстракции предметной области (или на уровне метапрограммирования), интерфейс пользователя оперирует совершенно другим аспектом той же задачи. То есть, разделать нужно не данные, логику и представление (их-то нужно скорее выделять, чем разделать), а абстракции или аспекты задачи.

5. Нет идеального кода, нужно довольствоваться какой-то степенью универсальности.

Мне, как идеалисту и перфекционисту, осознать это было сложнее всего. Мне бы волю, то программный код бы совершенствовался до умопомрачения, вплоть до того, как программа не начала бы решать все мыслимые и не мыслимые задачи и стала бы называться просто “программой”. Доведение до абсурда может быть завершено только на протяжении бесконечного времени, а оптимизация кода должна устремить его длину к нулю. Такая программа просто обязана решить все задачи программирования раз и навсегда. Но на практике нужно совсем другое, а именно – решить прикладную задачу, которая не так уж и требует идеального кода. Конечно, код должен радовать своей красотой, но не увлекайтесь.

6. Любой экстремизм плох.

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

7. Развитие системы ведет к ее ограниченности.

Любая система, в том числе и информационная, для развития требует принятия решений, но каждое решение приводит не только к появлению функционала, но и к созданию ограничений. Поэтому, вводя допущения и (assumptions) принимая решения, всегда думайте, к каким ограничениям это ведет и готовы ли вы к ним.

Это все. Надеюсь, кому-то пойдет впрок.
Timur Shemsedinov @MarcusAurelius
карма
160,5
рейтинг 0,0
Архитектор github.com/metarhia
Самое читаемое Разработка

Комментарии (148)

  • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      Опытного человека сразу видно, и мысли изложены замечательно. Вот только чувствую — набигут.
      • +5
        *набигает*
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        А меньшая часть Хабра (уверенно пишушая на Си) вообще не считает php-программистов программистами )))
        • +2
          web-программирование на С?
          Месье знает толк в извращениях.
          • +2
            Хороший Си-программист, напишет WEB-морду (и многое другое) на Си, лучше чем плохой РНР-программист на РНР (и наоборот)

            Нет плохих языков (и не только программирования) есть люди которые умеют писать (и говорить) а есть те кто только мычат и сопли жуют…
            • –6
              Вам лично рекомендую писать сайты на ассемблере.
              Чем дольше тролль будет занят ерундой, тем больше пользы от его отсутствия.

              Дальше кормить не буду.
              • +1
                А где тут троллинг? Или вы зашли в личку и посмотрели на минусы? Человек высказал своё мнение и высказал вполне адекватно. То, что мнение не совпадает с вашим не значит, что Vladson троллит
                • –1
                  Странно, что вы не заметили прямого переход на личности.
                  А карму я уже потом увидел.

                  Что касается мнения, то мне доводилось писать на с++ под web. Но даже в страшном сне не приходило в голову писать не специфичный кусок, а приложение полностью. Разве что на cern-овском C++ интерпретаторе. Но и это микроскоп для гвоздей. От реальности бесконечно далекий.
                  • +1
                    Да, таки стоило внимательно дочитать до конца. За последние полпредложения Владсон — неправ, согласен.)
                  • –1
                    Не знаю где вы уловили троллинг и тем более переход на личности, это факт и давно известный.
            • 0
              Vladson, я с вами не совсем согласен вот в каком плане.
              Писать веб-морду на Си можно только в своё удовольствие. В материальном плане это невыгодно, пусть это будет даже самый лучший в мире программист на Си.
            • +1
              В современном мире важнее «быстрее» и «дешевле». Да и поддержка веб-морды на Си скорее всего окажется сложнее и дороже поддержки аналогичной морды на PHP при сравнимой квалификации.
  • –1
    Прописные истины — это должно быть понятно каждому
  • 0
    теги радуют
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Это как философские знания или законы физики. Всегда были и для тебя кто их знает, конечно, это баян. А для многих не посвященных, возможно, откровение =)
      • +1
        Для «многих не посвященных» содержимое этого топика скорее вредно, чем полезно. Потому что они не смогут понять, когда необходимо использовать эти советы и будут ими оправдывать свой говнокод и нежелание изучать многие хорошие вещи.
        • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Не попал сразу.

          верно это… Но вот что теперь не писать по сути полезную информацию из-за того, что ее как то не там могут трактовать недоумы? )

          Статья есть и каждому решать, что с ней делать.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        верно это… Но вот что теперь не писать по сути полезную информацию из-за того, что ее как то не там могут трактовать недоумы? )

        Статья есть и каждому решать, что с ней делать.
  • +1
    Может мне показалось, но вы кидаете много камней в огород пхп =) Не так все плохо вокруг. Думать не сразу получается правильно, но наступая на грабли и видя как наступают другие, со временем понимаешь в чем суть.
    • +6
      На воре и шапка горит.
      Лично я не заметил никакой конкретики: ни явного указания платформы, ни явного указания языка.

      2 MarcusAurelius: пасибо большое, такой трезвый взгляд приходит только с опытом.
      • +4
        Тэги, фреймверки, зачем ооп если скрипт запускается на доли секунд, единственный полностью процедурный язык, пример шаблонизатора… Это было лишь предположение.
        • 0
          Теперь мне полностью понятно ваше предположение.

          Но если выбросить пункт 1.4, то статья становится явно без какой-то привязки к платформе.
  • –31
    И ни одного примера кода. В топку такую статью, так как она состоит из общих слов и придраться не к чему, а у меня паросто ощущение что автор не осилил ни ООП, ни MVC, и придумывает предлоги чтобы оправдать кривокод в стиле Perl/PHP 3.
    • +3
      Вы уверены, что с ООП и MVC получается не кривокод?
      • +2
        Конечно, это ведь модно и круто.
  • +20
    Статья хорошая, но у меня есть дополнения по пункту 1.1, а именно про ООП и классы.
    Верно, иногда от ООП можно отойти. Но если проект хоть сколько-то большой и масштабируемый, то это будет первая фатальная ошибка и, возможно, последняя.

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

    Наследование — это очень важный инструмент ООП, но злоупотреблять им не стоит. Наследование — это повышение сложность программы, а именного мы и хотим избежать с ООП. Я еще раз говорю, это не значит, что наследованием пользоваться плохо, это значит, что не надо злоупотреблять.

    И, конечно, инкапсуляция. Скрывать все надо до тех пор, пока что-то можно скрывать. Имхо, идеальным кодом можно назвать тот код, что все скрыто на максимально возможном уровне: детали реализации, передаваемые типы и т.д.

    Просите за К.О., но раз уж такая тема.
    • +7
      Раз пошла такая пьянка… Те кто начинают ООП с написания класса попадают на одни и те же грабли. Пишут суть обертку. Потом еще и еще. Выходят божественные объекты, делающие все и вся.

      По хорошему, ООП должно писаться с интерфейсов взаимодействия (схемку набросать не помешает однозначно), т.е. с написания абстрактного объектного кода, через который видно взаимодействие между объектами.
      А вся реализация обработки должна будет написана потом, когда интерфейс между объектами «устаканится». Над инкапсуляцией в этом случае, не нужно думать. Ясно, что все будет инкапсулировано, что не вошло в интерфейс.

      Кстати в этом плане использование TDD — правильный путь. Тесты описывают поведение системы. Тесты пишутся до кода, давая понять, что же мы хотим от системы и не давая зациклится на какой-то мелочи реализации, пытаясь довести себя до оргазма идеальным кодом.
  • 0
    > 1.4. Общественное помешательство на шаблонизаторах мне не вполне понятно, ведь большинство скриптовых веб-языков сами являются шаблонизаторами. Самый яркий пример – это PHP: переменные подставляет, циклы и ветвление есть, а главное, что все это не требует дополнительного парсинга шаблонов. При внедрении акселераторов, шаблоны будут прекомпилироваться в байт-код так же, как и все другие части программы.

    Не согласен. PHP это как раз пример того, как не следует делать. Если в конечном итоге будет байткод, то лучше для человеческого восприятия использовать шаблоны, т.к. некоторые вещи, которые мне доставались по наследству имели такое месиво из кода и шаблонов, что разгребать было сложно.

    В остальном согласен. Не всегда нужен ООП, не всегда РСУБД итд итп.
    • +6
      использовать возможности php как шаблонизатора и месево из html и php-кода это какбэ разные вещи
      • –6
        Объясните это тем, кто в этом нуждается.
      • +1
        Использовать возможности php как шаблонизатора прежде всего небезопасно. Разработчик шаблона может (случайно или нарочно — не суть) вывести пользователю данные, которые выводиться не должны, а то и пользователь их знать вообще не должен. Хороший шаблонизатор скомпилирует шаблон на свой языке в практически такой же код, который напишет человек ручками, но при этом не позволит человеку сделать потенциально небезопасные вещи, что на PHP очень легко, т. к. практически любой код имеет доступ к глобальному пространству имён, а если вспомнить про рефлексию, то и ко всем, даже приватным, свойствам и методам объектов.

        Да и писать (и читать) код под шаблонизаторами синтаксически проще, хотя бы не нужно постоянно помнить про экранирование вывода и выключать его только когда это действительно нужно. <?php echo htmlspecialchars($data['object']->name) ?> (пускай даже <?= _($object->name) ?>) всяко сложнее, чем {{ object.name }} (особенно, если редактор/IDE поддерживают подсветку синтаксиса и автодополнение для шаблонизатора). Ну и такие «мелочи» как блоки и наследование шаблонов позволяют не писать не очень очевидный и громоздкий кода типа:
        ob_start();
        include 'main_page.html.php';
        $content = ob_get_clean();
        $include 'layout.html.php';
        

        • 0
          Ну на счёт последнего — в фреймворках это обычно абстрагированно в что-то типа, но, в целом, с идеей согласен:
          <?= new View('header') ?>
          
          • 0
            Абстрагируется, конечно. И какие-то наследование с блоками могут быть, и другие плюшки (функции/методы вплоть до идентичности «сигнатуры» с тегами). Но синтаксически шаблон на PHP избыточнее явно, даже такие мелочи как '$', ';', '()', '->' оказывается снижают читабельность и даже скорость разработки шаблона.
      • +2
        php как шаблонизатор слишком многословен, плюс при перемешивании php и html блоки кода (начало и конец всяких if, for и прочих) становятся не так очевидны, как в случае с шаблонизаторами. Для сравнения, php и twig:

        <h1><?php echo htmlspecialchars($something); ?></h1>

        <h1>{{ something|e }}</h1>

        Шаблонизаторы оптимизированы на читабельность и лаконичность. PHP — нет.

        К тому же, с шаблонами легче разобраться дизайнерам/верстальщикам.

        P.S.: Ну да, в php есть короткие теги, в том числе вида <?=. Проблема в том, что в самой документации сказано, что лучше их не использовать.
  • 0
    Хорошая статья, не помешает прочитать каждому.
  • +3
    Хотелось бы написать: «Еще один все понял»… Но тут как раз обратная ситуация. И в особенности к PHP.

    1.1. ООП и фреймворки (свои или чужие) требуется для больших сайтов, без него будет очень сложно, особенно если необходимо не только сделать, но еще и поддерживать проект. На этом точка. Большая, жирная точка, и другого не дано;
    1.2. Иерархическая структура разобьется вдребезги и будет запутанная в случае большого проекта раскиданного по многим серверам;
    1.3. Правильно, применяется только то что требуется для проекта;
    1.4. Шаблонизаторы необходимы и в PHP, при этом они значительно ускоряют разработку в команде, но для двухстраничного сайта — это не нужно.
    1.5. Это идеальный пункт!.. Зачем покупать стул? Ведь Вы можете его сделать сами из подручных средств. Этот пункт просто уничтожает open-source, прям мечта какая-то. :)

    if ( $project = «Гостевая книга» ) {
      $rules = true;
    } else {
      print "
      Сайт написанный по Вашим правилам, будет идеальным руководством «Как делать нельзя».
      Тот кто будет поддерживать или дополнять в дальнейшем этот сайт — будет проклинать Вас на чем свет стоит.\n
      В народе данное \«творение\» называют — быдлокод.
      ";
    }
    • +3
      Афтар не читатель, афтар пейсатель?
    • +2
      1.1 Как показвыает практика (не будем показывать пальцем) некоторые и без фреймворков и ООП жуют по 10млн пользователей. Использовать чужие фреймворки? в больших проектах? :) Нет уж лучше свои написать, «лучше полчаса потерять, а потом за пять минут долететь» (ц). По целому ряду причин.

      1.2 Закрыть в комнате дать Маконнела и Фаулера, не выпускать пока не будет связно отвечать =)

      1.3 ???

      1.4 Шаблонизатор Smarty да, не нужен. =) Есть же прекрасный Blitz =)

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

      Пример вашего кода не имеет ничего общего с процедурным программированием =)
    • 0
      У вас аватарка не грузится
  • +5
    1.1. Я, наверное, не просто так указал "(свои и чужие)", и я не противник фреймворков.
    10 млн пользователей, без ООП, на Пыхе — нет уж покажите пальцем, фото тех кто их поддерживает было бы приятным бонусом.
    1.2. Бред.
    1.3. По статье прочитайте.
    1.4. Не важно какой. У каждого инструментария своя секта.
    1.5. Модный ныне хайлоад[x]. Зачем Вам Blitz, зачем Smarty — пишите свой шаблонизатор. Зачем Wordpress — пишите свой блог, это полчаса, а потом за пять минут долетите.

    Простите, в irony брать код — это «фи!».
  • +6
    Разворачивать классы и объекты в памяти имеет смысл в таких задачах, когда инстанс приложения будет жить хоть какое-то продолжительное время. А когда скрипт запускается чтобы за доли секунды отдать ресурс, то разветвленные концептуальные классы совсем ни к чему.

    У типичного cgi/php так всегда. Но очень часто код на базе процедурной парадигмы будет сложнее и хуже читаем чем код на базе ООП. Так что ООП стоит применять там где процедурное программирование уже замедляет разработку, а не ускоряет ее.

    Кто сказал, что для наследования и переопределения, обязательно нужны объекты? Вполне подойдет иерархическая файловая структура или иерархические запросы к базе.

    Не слишком удачная идея. Все уже украдено придумано за нас. Есть такая штука как namespace вот ими и надо пользоваться. Причем желательно с ООП. Стреляет такое на больших и долгоживущих проектах.

    Если Вас беспокоит, что код выглядит не круто, а даже совсем просто, но поставленную задачу все ровно выполняет, то стоит пересмотреть свои представления о программировании.

    Чем проще код тем лучше. Постигается сопровождением любого софта в течении пары месяцев.

    Общественное помешательство на шаблонизаторах мне не вполне понятно, ведь большинство скриптовых веб-языков сами являются шаблонизаторами.

    Это больше касается разделения логики и представления. И опять же касается больше PHP. Да php сам по себе хороший шаблонизатор, но не всегда. Ну а вот оно компилируется, а это не совсем правда. Тот же smarty после первого запуска создает скомпилированный шаблон на php ну а дальше если он есть использует его для представления отображения.

    Сейчас многие руководствуются принципом “скачать из интернета и прикрутить”, но даже если времени мало, то хоть просмотрите скачанный код, возможно, это натолкнет на мысль, как то же самое сделать более просто.

    Это хороший принцип. Единственное но это оценка качества. Для этого достаточно определить решает ли эта библиотека задачи которые вам нужны и что у нее с документацией. Чем хуже документация, тем больше вероятность некачественного кода.

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

    Возможно отделить везде. Проблема в другом, будет ли это приносить бенефиты? В вебе MVC приносит бенефиты, так-как упрощает разработку и объем охватываемых программистом данных. В других областях этого может не произойти.

    Нет идеального кода, нужно довольствоваться какой-то степенью универсальности.

    Закрепите фукнционал на итерацию и все. Это наиболее правильный вариант. Остальное от лукавого.

    • +3
      >У типичного cgi/php так всегда. Но очень часто код на базе процедурной парадигмы будет сложнее и

      Автор имел ввиду что пихать ООП везде — зло, требуется всегда соблюдать баланс между читаемость здравым смыслом и целями.

      >Не слишком удачная идея. Все уже украдено придумано за нас. Есть такая штука как namespace вот ими и надо пользоваться. Причем желательно с ООП. Стреляет такое на больших и долгоживущих проектах.

      ООП надо использовать лишь там, где оно необходимо — это давно известный факт но почемуто люди упорно пытаются написать везде и все на ООП, прикрутить классы к JS и т.д. Вместо того чтобы пользоватся ООП как инструментом — где и когда нужно, а не ВСЕГДА.

      • 0
        Автор имел ввиду что пихать ООП везде — зло, требуется всегда соблюдать баланс между читаемость здравым смыслом и целями.

        Автор пишет про время выполнения. А оно меньше зависит от сложности логики.
        • +1
          Ну правильная функционалка по накладным расходам всегда опеережает ООП из-за того что ей не требуется время на созданих своих сущностей.

          Или я не так понял?
          • +1
            Ну правильная функционалка по накладным расходам всегда опеережает ООП из-за того что ей не требуется время на созданих своих сущностей.

            Ничего подобного. Разница там реально маленькая при простой иерархии. Не надо просто фигачить объекты ради объектов и все.
            • 0
              Здесь согласен, но ИМХО при простой иерархии проще читаемо и поддерживаему всетаки функциональное программирование — я не про неймспейсы или чтото другое, а про то, что ради простой задачи где можно обойтись несколькими функциями нет смысла делать ООП вообще. зачем?
              • 0
                но ИМХО при простой иерархии проще читаемо и поддерживаему всетаки функциональное программирование

                У меня вот есть такой код 10 структур + 60 функций. Вот знаете в ООП явно проще это все было читать и обозревать.
                • 0
                  Ну при таком колве фий конечно ООП лучше.

                  Просто частенько (Не в Вашем случае а вообще) такие вещи могут быть из-за плохой орагнизации модели (неграмотное проектирование), которая потом переложена на функционал.
                  • 0
                    Фишка в том что процедурный код сложнее организовать.
                    • 0
                      Это зависит от:

                      a) задачи
                      б) специалиста

                      Надо применять разные подходы в заисимости от задачи.
                      А дальше дело за тем как это будет реализовывать выбранный специалист.
                • +2
                  А по-моему дело привычки. Я процедурный код читаю не хуже чем ООП.
                  • 0
                    Уточню: хороший процедурный код, грамотно разбитый на модули и функции.
  • –3
    Не знаю как у вас, но у нас, в России, нормальные шаблонизаторы парсят темплейт один раз. Если вам достаточно убогопхп в качестве шаблонизатора — отлично, но обычным людям надо меньше боли, поэтому они прибегают к помощи нормальных шаблонизаторов, это как раз ложится в вашу теорию о том, что нужно использовать то, что нужно, так что это пункт по всей видимости лишний.
    • 0
      Как шаблонизатор не назови, он все равно будет оверхедом
      • 0
        Нормальные шаблонизаторы позволяют отключить проверку на отпарсенность так что оверхеда может и не быть никакого, но даже если будет — он точно не будет узким местом.
  • +14
    От знаете чего меня умиляет больше всего?

    Какая бы не была хорошая статья на хабре про вебдев,
    все время все скатывается на то что пхп — гавно + обсуждение какихто фреймворков.
    А по шире чуток мыслить нельзя? :-D

    Автору респект ваще — одно дело когда ты этим просто руководствуешься,
    другое — собрать это систематизировать и написать — уважуха короче!
    • +3
      А в любой статье про брауеры всё сходится к тому, что IE — отстой + обсуждение оперы/фф/хрома.
  • 0
    За 4 пункт отдельное спасибо. Давно это понял, но не сфорсулировал для себя так чётко.
  • 0
    Спасибо за простое и понятное изложение здравого смысла в программировании :) а то иногда кажется, что код делается ради кода или + на хабре.

  • +13
    8. Не нужно прыгать выше головы. Оставайтесь тем кто вы есть — простым говнокодером. Умники придумали ООП и парадигмы для того чтобы их код не могли читать нормальные пацаны, а на самом деле самые понятные программы писались на перфокартах для ткацких станков. Вот тогда житуха была. И вообще чем больше операторов GOTO тем программа быстрее компилируется. Так что не стоит смотреть на то что все производители ПО скатываются в сраное ООП и шаблоны. Это они делают потому что сами не понимают выгоды структурного программирования и макаронного кода.
  • +1
    Отлично написали про перфекционизм. Такая же проблема. Редко удается абстрагироваться от программирования и просто решить задачу.
    • 0
      Я сам от этого себя отучиваю. Трудно…
    • 0
      А надо?
      Достигать совершенства в четко заданных пределах сродни умению писать хокку.
      Жестче правила — лучше результат.
      • 0
        Надо. Достигать результата совершенствуясь — вот мое хокку.
        • 0
          Смените масштаб. Внутри четко поставленное задачи остается «программирование ради программирования».
          • 0
            Ваши слова — мантра. Нужно практиковать и со временем возможно так и смогу четко ставить задачи, чтобы стало «программирование ради программирования».
  • +7
    Карьера опасносте!

    Внимания! Больше внимания! Данная статья пыщ пыщ ваш заработок!

    Вы можете согласиться с точкой зрения изложенной в данной статье только в том случае если вы не изучаете «бесчисленные парадигмы, концепции, инструменты и фреймворки» Иначе вам и в голову не придёт писать что-нибудь «проще и главное чтобы работало».

    В один прекрасный момент вы вдруг увидите, что человек который пишет тридцать три класса вместо вашей одной строчки Hello, World! получает зарплату в три раза больше, а перспектив у него в десять раз больше. Хотя он явно занимается какой-то ерундой, а вы изящно и просто решили задачу.
    • 0
      Это предположение или жизненный опыт?
      • 0
        Это статистика любой рекрутинговой конторы. Да просто оглянитесь вокруг и посмотрите кто больше получает и веселей шагает по ступенькам карьеры — тот кто виртуозно владеет парадигмами ООП (или виртуозно делает вид) или тот кто быстро выдаёт на гора конкретные, простые решения для очень узкой предметной области ака костыли?

        Подход описанный в статье был допустим ещё 5 лет назад. Сейчас, когда видишь что в твоём распоряжении целый завод, а не только текстовый редактор и нет никакого смысла самостоятельно что то оптимизировать, то просто не возникает никаких сомнений когда для очень простого функционала ты очень быстро пишешь десять классов или генеришь шаблон MVC. Мой скромный опыт в .net просто не оставляет вариантов для другого подхода. Это будет похоже на то что человек стоя рядом с 6-ти осевым обрабатывающим центром начинает на колене обтачивать поршень напильником. Это безусловно дешевле и может быть в каком то случае и приведёт к результату но в 99% случаев это указывает на профнепргодность. Во всяком случае это повод насторожится. Что вы делали последние три года если не изучали шаблоны, DDT, и MVC?
  • +1
    1.4 Категорически не согласен. Шаблонизаторы не нужны одному разработчику, но для команды — это точка пересечения ответственности. Шаблонизаторы помогают распараллелить процесс разработки, это их основной и незаменимый плюс.
    • +1
      Автор не отказывается от шаблонизаторов вообще, он предлагает использовать шаблонизатор от php.
      • 0
        Как вы себе это представляете? Лично мне не очень понятно.
        • +1
          Насколько я понял суть, имеется в виду нечто вроде следующего
          <?php foreach ($users as $user): ?>
          <?=$user['name'];?>
          <?php endforeach; ?>

          Подобный подход используется в битриксе например.
          Учитывая, что классические if и foreach во многих шаблонизаторах используются средствами шаблонизатора, когда можно использовать PHP напрямую. Все вычисления разумеется вынести наружу.
          С некоторой натяжкой можно сказать, что когда то PHP был шаблонизатором для Perl.
          По поводу рациональности использования такого подхода сказать что-то сложно, зависит от ситуации.
          • 0
            были ещё HTML теги, но их съел парсер=)
          • +1
            Это издевательство, а не шаблонизация. Читабельность кода по сравнению с тем же смарти, не сравнима

            {foreach from=$users item=«user»}
            {$user.name}
            {/foreach}

            Допустить синтаксическую ошибку в коде php в разы проще, чем в смарти
            • 0
              Ни разу не допускал, да и любой редактор php-кода такую конструкцию подсветит, провалидирует и т.д. и т.п.
              • 0
                Не знаю, мой редактор все что мне надо, подсвечивает. Шаблоны подсветки сделал за час.
              • 0
                А если переменная не задана — в шаблонизаторе на php notice выскочит, а smarty просто ничего не подставит, и еще много других плюшек
                • –2
                  Если переменная не задана — то пусть лучше выведет :) Ну и вывод нотисов при выполнении шаблона легко отключается через
                  $oldlevel = error_reporting(0);
                  // исполнение шаблона
                  error_reporting($oldlevel);
                  
            • 0
              Никто и не спорит. Однако сам PHP может служить сам себе шаблонизатором, так он устроен.
              Например, в документации к нашумевшему в последнее время в комментариях шаблонизатору Blitz написано: «В любом случае, если вы научились эффективно использовать сам PHP в качестве шаблонного движка, обходясь без сторонних продуктов и библиотек — вы счастливый человек. Вы используете самый эффективный с точки зрения производительности подход, и если он вам удобен — придерживайтесь его.»
              Лично мне писать на PHP как на шаблонном движке — просто неудобно.
              А вот поддерживать проекты, в которых используется PHP как шаблонизатор — наоборот проще (опять таки иногда), так как количество дополнительной документации, которую необходимо изучить, стремится к нулю.
            • 0
              А разве ваш код идентичен вышеприведенному? Smarty (давно им не пользовался) разве не экранирует вывод по умолчанию?

              А вообще, имхо, главное преимущество «ненативных» шаблонизаторов — они не позволяют сделать что-то вроде <?php mail('hacker@example.com', 'Password', $_POST['password']) ?> или <?php mysql_query('DROP TABLE users') ?>

              • 0
                Ничего не экранирует. Для экранирования есть отдельный модификатор escape
              • 0
                далеко не всегда это «преимущество ненативных шаблонов» вообще хоть кому-нибудь нужно. легенда о том, что
                {foreach from=$users item=«user»}
                сильно понятнее «неподготовленным верстальщикам» чем
                <?foreach($users as $user){?>
                довольно натянута, имхо.
          • –1
            <?=

            deprecated
            • 0
              Пруф
            • 0
              На самом деле deprecated только <%
              • 0
                Вообще есть такая рекомендация
                Using short tags should be avoided when developing applications or libraries that are meant for redistribution, or deployment on PHP servers which are not under your control, because short tags may not be supported on the target server. For portable, redistributable code, be sure not to use short tags.
                на www.php.net/manual/en/language.basic-syntax.phpmode.php
                • 0
                  Это не совсем «deprecated». Это значит, «если вы пишете либу, которая будет распологаться на чужом сервере — лучше не использовать короткие теги». Если вы разрабатываете приложение, которое будете лично поднимать на каком-то доступном к изменениям сервере, то это совершенно не актуально.
                  • 0
                    Читать я умею по-английски :) И, по-моему, это значит «Если у вас нет особых причин использовать короткие тэги, то лучше используйте длинные, т. к. неизвестно будут ли они включены или можно ли их будет включить там, где приложение или либа будут крутиться».
          • 0
            Не только в битсе. В drupal в модулях тоже можно такое же наблюдать. Выигрыш по скорости сомнителен, а вот поддержка такого кода, имхо, более накладная. Ни когда не жаловал тот же smarty считая его неким псевдоязыком над php, но если возникнет выбор без раздумий выберу smarty.
  • –2
    На Хабре как обычно. Пара нормальных комментариев и куча бесполезных высеров от людей, неспособных видеть дальше своего носа, обобщать и делать выводы. Противно! Статья ведь не о конкретном языке программирования, не о решениях в конкретных случаях. Статья вообще о подходе к программированию.
  • +1
    1.1 — отвратительный совет, не рекомендую ему следовать.
  • –2
    Афтар — вебдев?
    PHP в качестве шаблонизатора, не-MVC и без наследования объектов, говорите?
    Откройте для себя WordPress, ужаснитесь и перепишите статью.
  • +1
    "Неуместное и не адекватное использования инструментов встречается чаще, чем плохие инструменты."
    По сути дела вся негативная история компании майкрософт связана с этим принципом.
    • 0
      о боже, не пугайте нас — что же там такого негативного в истории microsoft?
  • –3
    Все правельно
    столкнулся с этим конга пришлось воспользоватся UMI CMS
    парни постарались на славу, применили там все что только знали
    у меня клиент просил убрать половину для его задачи, сделать это было не возможно слишком всё сильно завязано было.
    После этого вернулся к своей CMS-ке которая на много проще, но нет ни чего лишнего
    Хотя это мнение конечно программиста, для «верстальщика» такие монстры как UMI дают хоть какую то надежду поразить закачика ;)
  • 0
    Пока я работал программистом, я понял несколько вещей:
    1. Хороший программист может обходится тем, что ему нужно и писать так, как считает нужным. Будет не скромно, но моя система на которой построено куча достаточно больших проектов отлично подошла еще нескольким совершенно разным людям и в плане поддержки меня никто не ругал, поскольку все было просто и понятно, ни одного класса, обьекта или сложной запутанной структуры. Линейная программа с циклами, десятком функций и ветвлениями для ЛЮБОГО сайта который встречался в моей 6-летней практике.

    2. Если плохой программист сделал фреймворк, то это пичалька. Ругать будут все, не зависимо от того есть там обьекты/классы/иерархия и парадигмы или нет.

    3. Общедоступные фреймворки нужны как раз людям из пункта 2 и софтверным компаниям которые делают продукт «заказчику» и с большой текучкой кадров, чтоб люди были знакомы с продуктом, такой себе стандарт к которому все привыкли. Сайты клепаются десятками и это просто нужно. Если раньше одна софтверная компания делала 1-2-3 продукта для десктопа и занималась их поддержкой, то аутсорсерская фирма сейчас может делать 30 сайтов в месяц и за это время уволить и принять на работу 20 индусов. Потому стандарт нужен.
  • 0
    Пункт 5 гибелен только для тех, кто незнаком с понятиями «необходимость» и достаточность". Если это понимать, то «точка высшего совершенства» существует в реальности и достижима. Не «программа вообще», а «совершенное решение поставленной задачи».

    А то, что вы порицаете, называется «избыточность». Ни разу не имеющее отношение к «совершенству».
  • +3
    Избыточный перфекционизм это зло, да, но фреймворки и паттерны изучать надо — это путь к простоте через абстрагирование. По логике автора в веб-приложениях на PHP вредно использовать ООП, потому что объекты умрут через долю секунду. Но во что тогда превратится разработка и поддержка?
  • 0
    Пункт 6 вообще ни о чем. Так можно докатиться до «быстрое дешевле, чем долгое» и оправдать весь говнокод мира.
  • 0
    Пункт 7 некорректен изначально. Развитие системы вполне может снимать ограничения, а не добавлять. Так что — далеко не аксиома.
  • +4
    Задачи, где «старое доброе процедурное программирование» действительно (а не по причине плохого знания ООП разработчиком) эффективнее ООП, редки и нетривиальны, если речь, конечно, не о helloworld'ах и не о простых скриптах на коленке, в которых время решения непосредственно кореллирует с количеством набранных символов.

    Единственная здравая мысль — про шаблонизацию родными средствами PHP, остальное представляет собой смесь словоблудия и «вредных советов».
    • +3
      Я очень долго был приверженцем нативной шаблонизации, но последнее время она меня утомила.
      Шаблонизатор — это не только более короткий синтаксис, но и ещё куча плюшек, типа автоэкранирования и т.д.
      Хотя до сих пор использую нативный php, думаю перейти на twig
      • +1
        Аналогично, только уже перешёл :)
        • 0
          Тоже Твиг? И как впечатление?
          • 0
            Нравится :) Экранирование — бог с ним, действительно плюшка приятная, но не более. А вот наследование и блоки — это вещь. Ещё смотрел в сторону Blitz, но, имхо, большой порог вхождения и для разработки, а для разворачивания.
            • 0
              Недавно думал, чем же это так важно наследование… Есть пару зубодробительных примеров, которые действительно были бы удобными с наследованием, и которые очень тяжело делать без оного?
              • 0
                Например, трёхуровневую иерархию шаблонов (например, «шаблон сайта»-«шаблон раздела»-«шаблон страницы») с разными титлами, сайдбарами и, конечно, контентом сходу в голову не приходит как реализовать, чтоб получилось что-то вроде:
                <html>
                <head><title>{% block title %}Site title{% endblock %}</title></head>
                <body>
                <div id="content">
                  {% block content %}{% endblock %}
                </div>
                <div id="sidebar">
                  {% block sidebar %}
                    Our friends:
                    ...
                  {% endblock %}
                </div>
                </body>
                </html>
                

                {% extends base.tpl %}
                
                {% block title %}Articles - {{ parent() }}{% endblock %}
                
                {% block content %}{{ content }}{% endblock %}
                
                {% block sidebar %}
                  Popular articles:
                  ...
                {% endblock %}
                

                {% extends articles.tpl %}
                
                {% block title %}{{ article.title }} - {{ parent() }}{% endblock %}
                
                {% block content %}
                  <h1>{{ article.title }}</h1>
                  <div>{{ article.body }}</div>
                {% block sidebar %}
                  See also:
                  ...
                  {{ parent() }}
                {% endblock %}

                без, как минимум, кучи if'ов и повторения кода.

                Не знаю, так с непривычки понятно, или пояснить нужно?
                • 0
                  Мне пояснять не нужно :)
                  Чем эта запись лучше чем

                  <html>
                  <head><title>{$block_title|default:«Site title»}</title></head>
                  <body>
                  <div id=«content»>
                  {$block_content}
                  </div>
                  <div id=«sidebar»>
                  {$block_sidebar}
                  </div>
                  </body>
                  </html>
                  • 0
                    Где у вас будут задаваться block_*, разные для разных урлов (самый простой случай), с собственной разметкой, но возможно частично повторяющие родителя (по иерархии сайта)? Как зададите, что, грубо говоря, у /articles/1 титл должен быть article.name + титл /articles + титл /?
                    • 0
                      Последние мои наработки по шаблонизации звучат примерно так. Есть конвейер сборки шаблона. Есть разные типы «коробок», которые устанавливаются на конвейер перед запуском. В эти коробки разные модули накидывают свой контент или в виде готового html-кода, или в виде данных. Если есть «ответственный» за отрисовку данных, он трансформирует данные в html на основании своих шаблонов. Готовая сборка отправляется пользователю.

                      Какие именно модули будут участвовать в сборке — определяет пользователь при настройке страницы.

                      С тайтлом все просто. Есть «коробка» по отрисовке тайтла. Она на вход не принимает готовый html, только данные. Достаточно каждому модулю накидать данных по пути исполнения кода, и шаблонизатор отрисует их по собственному алгоритму. Это, я считаю, лучше, чем размазывание разных декоративных стилей оформления тайтла по многим сотням шаблонов.

              • 0
                Без оного можно сделать. Но одна проблема:

                Дизайнеру (верстальщику) проще работать с единой html страницей. Ну то есть от <html> и до </html>. При этом, желательно, чтобы дизайнер не пересекался с кодом приложения, и чтобы никакой html не оказывался вне директории шаблонов.

                Наследование — идеальное решение для этого. Создаём некий base.html, в котором базовый каркас (от <html> и до </html>), а потом для отличающихся дизайном страниц, создаём всякие page.html, catalogue.html, catalogue_item.html и так далее.

                Всё, что нужно для каждого конкретного типа шаблонов находится в отдельных файлах (а не разбросано по десятку маленьких файлов, как это получается в случае с include). Файлов получается меньше, распределены они логичнее, работать с ними проще.
                • 0
                  Это ООП подход. Он имеет место быть. Но он и негативен в определенных ситуациях.
                  Кусочечность дает хорошую повторяемость кода. Допустим, есть блок с табами. Изначально он имел одинаковую структуру. Потом, для пары случаев, сделали несколько исключительных изменений и поменяли структуру и обслуживающий код. Через время получается большая фрагментация кода. Править придется во многих местах, можно что-то пропустить, что-то забыть исправить.

                  В моих проектах вообще все по-другому сделано. Каждому модулю — локальные темплейны. Никаких пересечений и зависимостей от других модулей или темплейтов.
                  • 0
                    Такой подход губителен в крупных проектах. Написание скинов превращается в кровавую оргию с копипастом. Да и в небольших проектах аккуратное точечное применение фрагментации позволяет упростить жизнь.
                    • 0
                      Скины в крупных проектах? Простите, а кому она нафиг нужны? Людям работать нужно, а не играться с внешним видом.

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

                      Хотя, может я предвзято отношусь, нужно посмотреть на самые удачные реализации наследования шаблонов.
                      • +1
                        Ещё как нужны, причём именно наследуемые. Игра с внешним видом — это же основы маркетинга! В интернет-магазинах бывают различные акции и «сезоны скидок», бывают различные рекламные кампании — всё это требует оперативного переключения внешнего вида сайта (и, что ещё важнее — оперативной разработки оного!) Не следует понимать «скин» исключительно как возможность «поменять в личных настройках цвет форума с синенького на зелененький».

                        Пожалуй, таки да, предвзято относитесь :) Но проблема действительно сложная. Хоть шаблон и программа, но способа добиться внятного полиморфизма от этой программы в общем-то нет…
                        • 0
                          Вы знаете, у нас немного разные понятия крупных проектов. Я беру веб-ориентированные продукты для корпоративного сектора. Там объемы не сравнимы с форумом и магазином.
                          • 0
                            Пиписьками будем меряться или дело обсуждать? Даже онлайн-магазин — достаточно крупный проект, чтобы ощутить удушение копипаста в шаблонах.
                            • 0
                              Я не в качестве пиписькомера приводил пример, а в качестве факта наличия разницы между пониманием значений слов.

                              Потому что разные объемы порождают разные проблемы. Что хорошо для интернет магазина может быть совершенно не актуально для систем управления или корпоративного ПО. И наоборот. Что безумно важно для корпоративного ПО — бестолково применять в магазинах. Магазины ориентированы на продажи, которые делаются при помощи маркетинговых фишек, удобства пользования, информативности витрин, скорости работы. Скины важны для магазина. А ПО по управлению внутренним документооборотом должно быть унифицированным в качестве интерфейсов, максимально эффективно использовать рабочее пространство, быть максимально модульным, высокопроизводительным в плане скорости работы оператора с системой. И тут уже копипаст шаблонов или скины ну как-то совершенно вторичны. Скорость разработки логики модуля может быть в разы дороже по времени, чем ручная пересборка или правка шаблонов. Так что для каждой проблемы нужно искать самое эффективное решение
                              • 0
                                Как копипаст может быть вторичен, если он бесконтрольно размножает ошибки? Или вы Чак Норрис и никогда не ошибаетесь? :)

                                Код есть код, его дублирование всегда порождало и будет порождать проблемы. Точно так же, как и тотальное наследование всего и вся, впрочем.
                                • 0
                                  Замечание уместное.
                                  Резюмирую. Экстремумы приводят к проблемам.
            • 0
              Вы забыли макросы, макросы!
      • 0
        Переходите, не пожалеете.
      • 0
        Забавно, у меня имел место обратный процесс :) Я много лет был апологетом Smarty, а сейчас предпочитаю обходиться без него, а в качестве плюшек — ZF-овские view helpers. Да, синтаксис не слишком удобный, но зато на порядок меньше оверхеда при большей гибкости. Шаблонизатор отлично изолирует логику представления, но я в какой-то момент поймал себя на том, что зачастую эта изоляция дороговато обходится. Например, внедрять все хелперы в Smarty в качестве плагинов — дикий головняк, практической пользы от которого очень мало, если не отдавать проект на растерзание заведомым говнокодерам.
        • 0
          Смарти коварен, так и хочется в него перенести исполняемый код. Но надо стучать себя по рукам. :)
          • 0
            Вы про {php}? Там же его запретить можно, что и надо делать первым делом. А исполняемый код пусть в плагинах живет.

            Другое дело, что интеграция с фреймворками идёт гладко ровно до тех пор, пока работа шаблона ограничивается выводом переменных. Как только идём дальше (например, хотим использовать хелпер url в ZF для генерации URL) — начинается адский оверхед, каждому хелперу нужен прокси-плагин.
            • 0
              Нет, я про модификаторы и функции, которые можно писать самому. Иногда доходит до таких вариантов

              {get_data from=«table_name» where=«a='1' AND b='2'» assign=«res»}

              :)

              или вот до таких

              {«select * from 'table_name'»|sql_exec:«res»}

              Лень писать логику отдельно, представление отдельно, приводит разработчика к весьма «прикольным» реализациям
              • 0
                OMFG, ну это уже действительно порнография :)
              • 0
                И, кстати, лишнее доказательство того, что наличие шаблонизатора не отменяет необходимости думать. Ночной кошмар можно с равным успехом претворить в жизнь и на похапе, и на Смарти.
                • 0
                  :) Про это и речь.

                  Если подойти с головой, то можно действительно творить чудеса, при этом код будет высокочитабельный. И все это не будет выходить за рамки логики темплейтирования
        • 0
          Попробуйте twig :) Внедрение отдельного хелпера — одна строка, а если хелперы не проектноспецифичны (как в случае с фреймворками/библиотеками), то расширение twig это ещё несколько инфраструктурных строк. Относительно сложно только тэги новые вводить, а функции, фильтры и т. п. элементарно.
  • +9
    Сложилось впечатление, что автор никогда не работал на больших проектах, в команде и в энтерпрайзе, со всеми его проблемами и бардаком.

    1.1. ООП неэффективно только в совсем уж коротких скриптиках. По поводу производительности и серверных приложений вообще чушь какая-то. Время разработчиков стоит СИЛЬНО больше железа, соответственно, тратить его на разгребании вермишели…

    1.2. Чушь. Вы не понимаете для чего нужно наследование.

    1.3. У вас странные представления о «крутом» коде и о паттернах. Крутой код — тот который легко читать, в котором легко разобраться и, который ЛЕГКО расширять.

    1.4. А как же принцип разделения логики и представления? Не являюсь пхп-программистом, но логика внутри шаблона — это же ужасно с точки зрения читабельности.

    1.5. Если библиотека спроектирована правильно и выполняет задачи с заданными требованиями и ограничениями нет никакого смысла лезть внутрь, кроме случаев когда ее нужно расширять. Достаточно интерфейса. Если это фреймворк (а фреймворк — это НЕ библиотека) — то разработка под ним как раз и осуществляется за счет его расширения, соответственно, и знать его изнутри НАДО.

    2-3. Да, согласен.

    4. Выделять можно и НУЖНО. Опять же в целях читабельности, расширяемости и так далее.

    5. Почти согласен. Но нужно учитывать что большинство систем все-таки живет постоянно развиваясь. Решая задачи нужно стараться оставлять возможность для расширения.

    6. К сожалению, этот пункт слабо относится к содержанию статьи и выглядит как попытка оправдать свое мнение.

    7. Чушь, кроме случая плохо спроектированной системы, развитие которой приводит к вермишелеобразности. Лечится живительным рефакторингом.
    • 0
      Респект.

      Насчёт 1.4 — тут такая фишка: шаблон — это тоже программа. Даже голый HTML является программой отображения страницы в браузере. В шаблонах голый HTML разбавлен дополнительными инструкциями, формирующими — сюрприз! — логику представления. Естественно, эта логика решает задачи типа «вывести в таблице список значений», а не делает SQL-запросы к базе. PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.
      • 0
        >PHP для этого вполне подходит, другое дело, что такой подход требует определённой дисциплины.

        Зачастую использование PHP в качестве шаблонизатора противоречит 3-му пункту статьи
        3. Неуместное и не адекватное использования инструментов встречается чаще, чем плохие инструменты.

        У каждого языка и технологии есть круг задач, для которых он подходит как нельзя лучше, а для других задач наверняка есть свои адекватные средства решения.

        Как ни странно, но язык, создаваемый когда-то в качестве шаблонизатора и переросший через язык серверного веб-программирования в язык общего назначения («де-юре», как минимум), для использования в качестве шаблонизатора подходит теперь хуже, чем узкоспециализированные шаблонизаторы. С другой стороны, и для другой логики, кроме логики отображения/представления он не идеален, особенно если рассматривать не голый язык со стандартными библиотеками, а всю «экосистему». Явное преимущество PHP нынче, имхо, это «унаследованная» и «самоподдерживаемая» популярность его самого, продуктов написанных на нём (CMS прежде всего) и предложений хостеров, то есть по сути преимущество только маркетинговое, раскрученный бренд даже среди людей мало связанных с вебом.
        • 0
          Шаблнизаторы — не панацея. Я много лет работал со Smarty и другими шаблонизаторами, потом вернулся к нативной шаблонизации. Не хотелось бы начинать холивар ради холивара, есть преимущества у обоих подходов, в том числе и множество преимуществ у нативной шаблонизации. Единственный безусловный минус — verbosity, это действительно раздражает.
          • 0
            Насчёт множества преимуществ — я три насчитал:
            — скорость — безусловно, но вот практически её влияние не всегда заметно
            — «чистота» — отсутствие необходимости что-то подключать, что-то изучать и т. п.
            — гибкость — все возможности языка к вашим услугам без лишнего оверхида, но даже тут ограничения: синтаксис языка расширить не получится, например ввести для цикла ветвь для пустого цикла нельзя

            Недостатки:
            — громоздкость — вы это verbosity назвали
            — небезопасность — обратное следствие гибкости, разработчику шаблона доступны все данные приложения, а то и сервера, плюс нет автоэкранирования
            — необходимость самодисциплины — тоже обратное следствие гибкости, запихнуть в шаблон получение, а то и изменение данных БД никто не мешает
            — отсутствие «из коробки» удобных фич типа наследования шаблонов и того же автоэкранирования

            А так, конечно, не панацея и надо выбирать критичность для проекта плюсов и минусов разных подходов. Но, как мне кажется, для большинства проектов скорость и гибкость шаблонизации не так важны, как безопасность и удобство.
      • 0
        Согласен.

        Но вот если использовать не MVC, а немного более прогрессивный MVVM, то вся логика представления (кроме разве что итераторных циклов) внезапно оказывается там где ей и положено быть — в контроллере.
        • 0
          Не нашёл примеров MVVM не завязанных на Microsoft, а с ними и половины не понял.

          Разве в контроллере должен быть код вроде
          <? if ($a): ?>
            <h1 class='normal'><?= $a ?></h1>
          <? else: ?>
            <div class='error'>Empty!!!</div>
          <? endif ?>
          

          ?
          • 0
            У Фаулера он зовется «Presentation Model» — martinfowler.com/eaaDev/PresentationModel.html.

            Грубо говоря — заводится так называемая «Модель представления» (может быть и неким конвертером из обычной модели с логикой, но обычно тупо класс с набором полей или даже просто словарь), которая заполняется в контроллере. В шаблоне логики нет, только подстановка полей из модели представления в нужные места.

            Собственно, на самом деле, многие MVC-фреймворки на деле не MVC, а именно MVVM.
            • 0
              Ну да, что-то похожее и используется по факту часто — во вью/шаблон передаётся какая-то структура данных и больше ни к чему они доступ не имеют (другое дело, что часто передаются объекты модели непосредственно, как элемент словаря). Но вот полное отсутствие логики в шаблоне как-то смущает. Где определять какой блок/контрол/тэг/«виджет» (h1 или div в примере выше) выводить в зависимости от данных, как не в шаблоне? Можно, конечно, сделать как часто поступают в десктопных GUI, «нарисованных» в редакторах форм — выводить оба, но одному из них (вернее соответствующему полю ViewModel) прямо в контроллере присваивать состояние visible/hide, но для веба, по-моему, это неприемлемо на типичных страницах (где ajaх используется для расширения функциональности отдельных контролов, но основой остаётся обычный http-цикл).
  • –3
    Браво!
  • +1
    Общественное помешательство на шаблонизаторах мне не вполне понятно, ведь большинство скриптовых веб-языков сами являются шаблонизаторами.
    Это же очевидно. Это последствия разделения труда. Шаблонизаторы проще в использовании для непрограммистов (верстальщиков).
    • 0
      Да и для программистов зачастую проще, главное «войти в тему».

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