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

Версия 18:28, 21 сентября 2012

Slide Show

Автор: Виталий Филиппов
Дополнительный нижний колонтитул: Мода на коробки и фреймворки в вебе - доколе?

Содержание

1 Название доклада
2 Тезисы
3 План
4 Презентация
5 Мысли

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

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

Тезисы

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

План

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

Презентация

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

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

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

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

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

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

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

А потом… ⌘⌘

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

… и при этом:

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

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

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

CMS

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

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

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

;-)

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

Например,

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

Однако,

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

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

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

Можно… ⌘⌘ %%

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

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

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

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

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

* Wenger Giant Knife

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

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

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

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

Шаблонные,

не особо посещаемые,

быдлопроектики.

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

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

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

Но создателям CMS нужно продвигать свой продукт! ⌘⌘

А в людях всегда живёт:

Лень, желание получить результат, ничего не делая.
Мечта о серебряной пуле, которая решит все задачи!

Каждый более-менее сложный проект уникален!

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

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

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

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) ⌘⌘ %%

Мысли

Общность:

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

Что такое 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), фреймворки неэффективно обеспечивающие работу с произвольными атрибутными сущностями.

[1]

@@ Строка 144: / Строка 144: @@
 ;Проект {{green|посещаемый}} &rArr;: упрётесь в {{red|низкую производительность}}
-==== Что же остаётся? ⌘⌘ %% ====
+==== Что же остаётся? ⌘⌘ ====
 '''{{gray|Серая массовка}}'''
-Шаблонные,
+: Шаблонные,
+: не особо посещаемые,
-не особо посещаемые,
+: {{gray|быдло}}проектики.
-{{gray|быдло}}проектики.
 -----