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

Материал из YourcmcWiki
Перейти к: навигация, поиск
м (Вы спросите, а если сайт делает {{red|НЕ}}программист? ⌘⌘)
м (Вы спросите, а если сайт делает {{red|НЕ}}программист? ⌘⌘)
Строка 172: Строка 172:
 
* Группу в социальной сети
 
* Группу в социальной сети
  
Выхлопа будет больше, в том числе в плане маркетинга.
+
{{green|Выхлопа будет больше}}, в том числе в плане {{blue|маркетинга}}.
  
 
==== {{red|WARNING!}}<br/> Формулировка расплывчата ⌘⌘ %% ====
 
==== {{red|WARNING!}}<br/> Формулировка расплывчата ⌘⌘ %% ====

Версия 19:09, 21 сентября 2012

Автор

Виталий Филиппов
Дополнительный нижний колонтитул

Мода на коробки и фреймворки в вебе - доколе?

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

«Мода на коробки и фреймворки в вебе — доколе?» (ликбез для менеджеров)

Тезисы

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

План

  • Титульный слайд
  • О чём эта презентация?
    • Нужно сделать сайт. Варианты: CMS, фреймворки, кастом.
    • Что вы выберете? CMS? FW? А кастом — «Фууу, лунапарк с БДж&Ш??!», да?
    • ⇒ 1 и 2 вошли в моду, зачастую люди не думают о последствиях.
    • А истина в том, что каждый инструмент имеет область применения. У CMS она дико завышена, у FW частично тоже.
  • CMS
    • Что такое CMS? + Примеры.
    • Минусы (очень много) и плюсы (очень мало), область применения (узкая)
    • Пример: пройтись огнём по битриксу (жесть жестяная).
  • Фреймворки
    • Что такое фреймворк? + Примеры.
    • Сначала общие плюсы (мало) и минусы (много), идентичны оным Opensource-фреймворков.
    • Доп. минусы платных фреймворков (коих под PHP почти нет)
    • Доп. минусы внутренних фреймворков
    • Область применения
  • Специализированная разработка на основе библиотек
    • Однако плюсы!
  • Выводы

Презентация

Мода на коробки и
фреймворки в вебе — ДОКОЛЕ?! ⌘⌘ %%

(ликбез для менеджеров)

Monster-shadow-cms.svg

Виталий Филиппов, CUSTIS

Допустим, вам нужно создать интернет-проект ⌘⌘ %%

Что вы выберете?

Site-options.svg

Проблема моды ⌘⌘

Koza.svg
  • «Писать самим? Да вы что? Всё уже написано до вас!»
  • Есть же коробочные CMS! Поставил, и сайт готов! Супер-поддержка от компании-изготовителя!
  • А также куча модных фреймворков! Zend, CI, Yii! Паттерны, все и разом!

А потом… ⌘⌘

CryingFace.svg
  • «Хостинг стоит миллионы!»
  • «Сайт тормозит!»
  • «Медленно внедряются доработки!»
  • «Постоянно что-то отваливается!»
  • «Всё обросло костылями!»

… и при этом:

«Нет, надо ещё чуть-чуть докрутить, и цель будет достигнута!»

Надо было думать, когда выбирали! ⌘⌘ %%



…а не слепо следовать моде.
 

CMS

Что такое CMS? ⌘⌘ %%

CMS2.png

Что такое CMS? ⌘⌘

Sarcasm.jpg
  • Content Management System
  • Движок (ПО) сайта
  • ;-) …На котором можно сделать ЛЮБОЙ сайт
  • ;-) …Причём без единого гвоздя (строчки кода)


;-)

Смысл именно в общности применения ⌘⌘

Например,

  • MediaWiki, MoinMoin и т. п. — не CMS, а вики-движки (хотя сайт на них сделать можно)
  • PhpBB, IPB — движки форумов

В то же время,

  • WordPress — был движком для блогов, а стал CMS
  • osCommerce, Magento — спец. CMS, движки интернет-магазинов
  • Joomla, Drupal, MODx, NetCat, Битрикс, UMI.CMS — это всё CMS

Стандартная фраза: ⌘⌘ %%

«…это программный комплекс, позволяющий создавать веб-сайты любого уровня сложности…»

Koza.svg

Можно… ⌘⌘ %%

…Говорить и о «специализированных CMS».

(и вообще любой движок сайта называть CMS)

Но я говорю о коробочных, «ужеготовых» CMS.

Популярные CMS — монстры ⌘⌘

  • Сложные
  • Неэффективные
  • С кривой архитектурой
  • С кучей лишнего функционала

А всё дело в том, что… ⌘⌘ %%

Не существует универсального инструмента!

Wenger giant knife.png


* Wenger Giant Knife

Wenger Giant Knife

Причём что характерно — сколько бы вы думали он стоит ? 100$ ? 200$ ?

А вот хрена с два! 2149.95 $.

Закон природы, такой же как и в случае с CMS: уродство ещё и стоит дорого.

Когда реально применять CMS? ⌘⌘

Проект простой
CMS неудобна, ибо слишком сложна
Проект сложный
возможностей CMS наверняка не хватит,
а плохая архитектура усложнит их реализацию
Проект посещаемый
упрётесь в низкую производительность

Что же остаётся? ⌘⌘

Серая массовка

  • Шаблонные,
  • не особо посещаемые,
  • быдлопроектики.

* Какие-нибудь «порталы» с копи-пи**ерами новостей…

Вы спросите, а если сайт делает НЕпрограммист? ⌘⌘

А тогда не надо его пускать за руль CMS!

Пусть лучше заведёт

  • Блог — ЖЖ / blogger / тематические (drive2.ru, …)
  • Wiki (например, на wikia.com)
  • Группу в социальной сети

Выхлопа будет больше, в том числе в плане маркетинга.

WARNING!
Формулировка расплывчата ⌘⌘ %%

Warning icon.svg

Поэтому если сомневаетесь — НЕ БЕРИТЕ CMS!

Дополнительные проблемы

  • Расчёт на доработку дешёвым ресурсом
    ⇒ и плачевные результаты
  • Закрытое ПО — политическая проститутка
    Ибо «любой каприз за ваши деньги»

ЭТАЛОН УЖОСА ⌘⌘ %%

1cbitrix.svg

1С БИТРИКС

Примеры «ужоса» ⌘⌘

«В профессиональной среде в ходу жаргонизм „говнокод“»

  • Стиль кода «портянка»: 2032 строки, (!!!) 0 функций
  • Само-DOS по 404
  • «Инфоблоки» — кривое объектное ядро, в студию!
  • MVC без модели!, «супер компонент»

Об ужасах битрикса

Несмотря на то, что интернеты кишат критикой данной коммерческой CMS, причём даже по сравнению с другими, бесплатными (открыто-свободными) CMS, она почему-то всё ещё популярна. Причина кроется, наверное, разве что в маркетинге, потому что нормальных программистов у них, по-видимому, нет. Регулярно происходят выступления на конференциях, на которых то расскажут, что очередная маркетинговая фишка — Web Application Firewall — родилась, когда поняли, что даже опытные программисты у них зачастую не экранируют параметры в SQL-запросах… то о том, что на задачу «завести битрикс в AWS» у них ушёл год… То ещё о чём-нибудь.

Но зато мы имеем отличный пример CMS’ки с ужасной архитектурой, можем бугагагировать и рассматривать антипаттерны реализации. Итак, избранные примеры ужосов:

Начать стоит с дикого для 21 века стиля кода (пещерный стиль). Многие компоненты написаны не то что не объектно-ориентированно, а даже не процедурно — так как в коде зачастую вообще отсутствуют процедуры, а просто идёт длииииинная портянка где-нибудь на 2000 строк. О каком-то структурировании такого кода речи, конечно, идти не может. О, скажем, наследовании я вообще молчу — оно там реализуется только с помощью копипасты.

Конторой на флаг поднимается то, что в битриксе есть MVC. При чём тут MVC — вообще непонятно: M — модель бизнес-объектов, инкапсулирующая логику работы с оными — там полностью отсутствует. Весь «MVC» заключается в том, что код компонента разделили на два файла — компонент и шаблон. Причём несмотря тривиальность этого разделения, среди битрикс-разработчиков находятся люди, которым оно не нравится; они изобретают (а то и находят на прострах интернета) довольно популярный антипаттерн «супер компонент», то есть пустую обёртку для шаблона, и всю логику пишут прямо в шаблоне. Один такой «супер компонент», например, изобрёл некто Иван Левый. Ну да — реально левый, что с него взять.

Прикольно реализована страница ошибки 404 «страница не найдена» — если, не дай бог, она обрабатывается битриксом, там будет 300 запросов в базу, и если, не дай бог, на главной окажется размещена битая ссылка, на которую будут заходить многие пользователи — сайт уйдёт в «само-DOS» (само-отказ-в-обслуживании), ибо обработка 404 съест все ресурсы.

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

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

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

Зато «мы стали более лучше одеваться!»* ⌘⌘

Зато Битрикс24! И магазин компонентов!

:-( печаль и уныние.


* «Овощи там, рожь!» © Света из Иваново

Фреймворки (PHP) ⌘⌘ %%

Frameworks.png

Мысли

Общность:

  • ЛЕНЬ! Вечное желание получить результат, ничего не делая.

Что такое CMS?

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

Минусы CMS:

  • Монстр — Сложная и Неэффективная
    • => Плохо подходит для посещаемых сайтов
      И посещаемый сайт сделать на CMS можно, но геморроя не оберёшься. Будут тормоза, будет дорогой хостинг, будут простои, будут падения при внесении доработок и даже, например, сбросе кэша.
    • Фредерик П. Брукс, "Мифический человеко-месяц или как создаются программные системы": сложность программной системы растет нелинейно при увеличении размера => отсюда все эти SOA и т. п.
  • И вы оплачиваете её неэффективность!
    • Деньгами хостингу серверов.
    • Деньгами продавцу коробки.
    • Деньгами подрядчикам, её дорабатывающим.
      Дешёвым — обычно несколько раз
  • Некрасивая архитектура, оптимизированная под «общий случай». То есть, не оптимизированная ни подо что вообще.
    • Простейший пример — EAV[1].
  • Расчёт на доработку дешёвыми подрядчиками (и, похоже, дешёвыми программистами самой CMS)
    • Как они там в битриксе параметры научиться экранировать не могут.
    • Нормальный, уважающий себя, разработчик в ЭТО потом вообще не полезет.
  • Вы оплачиваете и её сложность!
  • +++ Проституточная суть платного/закрытого.
  • Зачастую полезный функционал погребён под бесполезным и усугублён кривыми архитектурными решениями
  • Примеры:
    • Битрикс (должен быть стоп-словом)
      • «БИТРИКС ДЕТЕКТЕД» — вполне катит для отдельного раздела на говнокод.ру.
      • Битрикс можно снести с серверов, но нельзя убрать из головы.
        («Можно вывезти девушку из деревни, но нельзя вывести деревню из девушки»).
    • WordPress — внутри тот же битрикс, только открытый и менее коробочный.
    • Любые движки интернет-магазинов с EAV.
    • http://ru-anticms.livejournal.com/3931.html
    • http://ru-anticms.livejournal.com/

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

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

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

  • Почти все нужные абстракции в PHP уже есть => фреймворк даёт мало полезного функционала
    • Зачастую «умного» функционала, который мог бы быть очень полезен, как раз и нет, а есть только совсем шаблонные решения. Обёрнутые в классы, фабрики и фабрики фабрик.
    • Паттерн «Фабрика проблем».
    • If you have a Problem and decide to use Java, now you have Problem, ProblemImpl, ProblemException and ProblemFactory.
    • http://habrahabr.ru/post/141477/
  • Жирная зависимость => для библиотек не подходит. Библиотека под фреймворк — уже не библиотека, а плагин.
  • Простые проекты усложняет => для простого не подходит.
  • В сложных проектах жмёт => для сложного тоже не подходит.
  • Остаются «средние» проекты… (а это вообще что? обреченные проекты без развития?).
  • Вам могут тупо не понравиться практики, принятые во фреймворке, а от них никуда не деться.
    Одни фреймворки более пермиссивные, чем другие, и в них этот минус частично сглаживается.
  • Дополнительный источник багов и дыр.
  • Глобальные перетрахивания фреймворка, происходящие при обновлении языка (например php4 -> php5, неймспейсы) => возможно, придётся перетрахивать и ваш код
  • Очень обидно, если для переопределения чего-то нельзя обойтись без патчинга фреймворка — а такое бывает!
  • «Автобусный фактор» разработки некоторых фреймворков.
  • Внутрикорпоративные фреймворки — вообще отдельная песня. С ними решение — либо выводить в опенсорс, либо не особо сильно на них полагаться. Либо и то, и другое.
    • Алиментщик, PHP Jihad, «не дай бог join в коде увижу!»
  • Единственный плюс — для слабых разработчиков фреймворк может послужить:
    • а) ограничителем применения бурной неокрепшей фантазии (но его нужно «правильно готовить»);
    • б) подспорьем в обучении программированию при осмотре деталей реализации самого фреймворка.
  • OpenX

Вывод:

  • Всё как обычно с любой модой/предубеждением — «думай, прежде чем выбирать».
  • Полезное применение фреймворков шире, чем у CMS, но всё же относительно узкое.
  • Если фреймворк пермиссивный — возможно, он хотя бы не навредит.
  • Главный плюс рукотворный: PHP-фреймворки — это мода, упрощающая продажу менеджерам, которые слышали buzzword, но не разбирались в вопросе.
  • Плохо ли, что существуют CMS и фреймворки? Нет — это отражение прогресса. Хорошо хотя бы тем, что раз оно существует, его можно оценить и понять, нужно ли оно вам.
  • Она же OAV (object-attribute-value), фреймворки неэффективно обеспечивающие работу с произвольными атрибутными сущностями.