Мода на веб-фреймворки - тезисы — различия между версиями

Версия 01:12, 2 сентября 2012

Название доклада:

• «Мода на коробки и фреймворки в вебе — доколе?»

Тезисы:

• Как часто для разработки веб-проекта (не самого простого!) выбирается коробочная CMS, а потом, пока программисты яростно пытаются совладать с её недостатками, а за хостинг отдаётся миллион в месяц, менеджеры, несмотря ни на что, продолжают защищать свой выбор, аргументируя это тем, что «инструмент отличный» и его всего-то надо «немного подкрутить, и цель точно будет достигнута»?
• А как часто выбирается фреймворк (что, конечно, лучше CMS) и начинает обрастать костылями, потому что цели, под которые он разрабатывался, не совсем соответствуют целям проекта?
• Что общего в этих подходах? Во-первых, оба подхода рождаются из одного желания — желания создать (а зачастую и продавать!) продукт, который Вроде-Бы может решить… абсолютно ВСЕ задачи. А во-вторых, и то, и другое настолько «вошло в моду», что люди почти не задумываются о куче проблем, которые получат с выбором таких инструментов.
• Соображения именно об этой моде и о типичных проблемах, получаемых людьми вместе с ней, и хотелось бы донести в рамках доклада.

Что такое CMS?

• Движок, на котором «можно сделать всё», причём в идеале «без единого гвоздя» :)
• Смысл именно в спозиционированной общности применения.
• Скажем, MediaWiki — не CMS, хотя сайт на ней сделать тоже можно. WordPress — когда-то тоже не был CMS, а сейчас уподобился битриксу.

Минусы CMS:

• Монстр — Сложная и Неэффективная
  • => Плохо подходит для посещаемых сайтов

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

  • Сложность программной системы возрастает нелинейно при увеличении размера => отсюда все эти SOA и т. п.
• Вы оплачиваете её неэффективность!
  • Деньгами хостингу серверов
  • Деньгами продавцу коробки
  • Деньгами подрядчикам, её дорабатывающим

    Дешёвым — обычно несколько раз

• Некрасивая архитектура, оптимизированная под «общий случай». То есть, не оптимизированная ни подо что вообще.
  • Простейший пример — EAV.
• Расчёт на доработку дешёвыми подрядчиками (и, похоже, дешёвыми программистами самой CMS)
  • Как они там в битриксе параметры научиться экранировать не могут
  • Нормальный разработчик в ЭТО потом вообще не полезет
• Вы оплачиваете и её сложность!
• Примеры:
  • Битрикс (должен быть стоп-словом)
    • «БИТРИКС ДЕТЕКТЕД» — вполне катит для отдельного раздела на говнокод.ру.
    • Битрикс можно снести с серверов, но нельзя убрать из головы

      («Можно вывезти девушку из деревни, но нельзя вывести деревню из девушки»)

  • WordPress — внутри тот же битрикс, только открытый и менее коробочный
  • Любые движки интернет-магазинов с EAV

Что такое фреймворк?

• Как и библиотека, набор заранее написанного функционала…
• Но фреймворк отличается от библиотеки повсеместным применением IoC.

Минусы веб-фреймворков:

• Почти все нужные абстракции в PHP уже есть => фреймворк даёт мало полезного функционала

  Зачастую «умного» функционала, который мог бы быть очень полезен, как раз и нет, а есть только совсем шаблонные решения. Обёрнутые в классы, фабрики и фабрики фабрик.

• Жирная зависимость => для библиотек не подходит. Библиотека под фреймворк — уже не библиотека, а плагин.
• Простые проекты усложняет => для простого не подходит.
• В сложных проектах жмёт => для сложного тоже не подходит.
• Остаются «средние» проекты… (а это вообще что?)
• Вам могут тупо не понравиться практики, принятые во фреймворке, а от них никуда не деться

  Одни фреймворки более пермиссивные, чем другие, и в них этот минус частично сглаживается

• Дополнительный источник багов и дыр
• Глобальные перетрахивания фреймворка, происходящие при обновлении языка (например php4 -> php5, неймспейсы) => возможно, придётся перетрахивать и ваш код
• Очень обидно, если для переопределения чего-то нельзя обойтись без патчинга фреймворка — а такое бывает!
• «Автобусный фактор» разработки некоторых фреймворков
• Внутренние фреймворки — вообще отдельная песня. С ними решение — либо опенсорс, либо не особо сильно на них полагаться. Либо и то, и другое.

Вывод:

• Всё как обычно с любой модой/предубеждением — думай, прежде чем выбирать
• Полезное применение фреймворков шире, чем у CMS, но всё же относительно узкое
• Если фреймворк пермиссивный — возможно, он хотя бы не навредит
• Главный плюс рукотворный: PHP-фреймворки — это мода, упрощающая продажу менеджерам, которые слышали buzzword, но не разбирались в вопросе