7
правок
Изменения
Нет описания правки
Название доклада:
* «Мода на коробки и фреймворки в вебе — вебе — доколе?»
Тезисы:
* Как часто для разработки веб-проекта (не самого простого!) выбирается коробочная CMS, а потом, пока программисты яростно пытаются совладать с её недостатками, а за хостинг отдаётся миллион в каждый месяцотстегиваются миллионы, менеджеры, несмотря ни на что, продолжают защищать свой выбор, аргументируя это тем, что «инструмент отличный» и его всего-то надо «немного подкрутить, и цель точно будет достигнута»?* А как часто выбирается жирный фреймворк (что, конечно, лучше CMS) и , который сразу начинает неудержимо обрастать костылями, потому что цели, под которые он разрабатывался, не совсем соответствуют целям проекта?* Что общего в этих подходах? Во-первых, оба подхода рождаются из одного желания — желания — желания создать (а зачастую и продавать!) продукт, который Вроде-Бы может решить… абсолютно ВСЕ задачи. А во-вторых, и то, и другое настолько «вошло в моду», что люди почти не задумываются о куче проблем, которые получат с выбором таких инструментов.
* Соображения именно об этой моде и о типичных проблемах, получаемых людьми вместе с ней, и хотелось бы донести в рамках доклада.
* Движок, на котором «можно сделать всё», причём в идеале «без единого гвоздя» :)
* Смысл именно в спозиционированной общности применения.
* Скажем, MediaWiki — MediaWiki — не CMS, хотя сайт на ней сделать тоже можно. WordPress — WordPress — когда-то тоже не был CMS, а сейчас уподобился битриксу.
Минусы CMS:
* Монстр — Монстр — Сложная и Неэффективная
** => Плохо подходит для посещаемых сайтов
**: И посещаемый сайт сделать на CMS можно, но геморроя не оберёшься. Будут тормоза, будет дорогой хостинг, будут простои, будут падения при внесении доработок и даже, например, сбросе кэша.
** Сложность программной системы возрастает растет нелинейно при увеличении размера => отсюда все эти SOA и ти т. пп.* Вы И вы оплачиваете её неэффективность!** Деньгами хостингу серверов.** Деньгами продавцу коробки.** Деньгами подрядчикам, её дорабатывающим.**: Дешёвым — Дешёвым — обычно несколько раз
* Некрасивая архитектура, оптимизированная под «общий случай». То есть, не оптимизированная ни подо что вообще.
** Простейший пример — пример — EAV<ref>Она же OAV (object–attribute–value), фреймворки неэффективно обеспечивающие работу с произвольными атрибутными сущностями.</ref>.
* Расчёт на доработку дешёвыми подрядчиками (и, похоже, дешёвыми программистами самой CMS)
** Как они там в битриксе параметры научиться экранировать не могут.** Нормальный , уважающий себя, разработчик в ЭТО потом вообще не полезет.
* Вы оплачиваете и её сложность!
**
* Примеры:
** Битрикс (должен быть стоп-словом)
*** «БИТРИКС ДЕТЕКТЕД» — ДЕТЕКТЕД» — вполне катит для отдельного раздела на говнокод.ру.*** Битрикс можно снести с серверов, но нельзя убрать из головы.***: («Можно вывезти девушку из деревни, но нельзя вывести деревню из девушки»).** WordPress — WordPress — внутри тот же битрикс, только открытый и менее коробочный.** Любые движки интернет-магазинов с EAV.
Что такое фреймворк?
* Почти все нужные абстракции в PHP уже есть => фреймворк даёт мало полезного функционала
*: Зачастую «умного» функционала, который мог бы быть очень полезен, как раз и нет, а есть только совсем шаблонные решения. Обёрнутые в классы, фабрики и фабрики фабрик.
:* Паттерн «Фабрика проблем».* Жирная зависимость => для библиотек не подходит. Библиотека под фреймворк — фреймворк — уже не библиотека, а плагин.
* Простые проекты усложняет => для простого не подходит.
* В сложных проектах жмёт => для сложного тоже не подходит.
* Остаются «средние» проекты… (а это вообще что? обреченные проекты без развития?).* Вам могут тупо не понравиться практики, принятые во фреймворке, а от них никуда не деться.*: Одни фреймворки более пермиссивные, чем другие, и в них этот минус частично сглаживается.* Дополнительный источник багов и дыр.
* Глобальные перетрахивания фреймворка, происходящие при обновлении языка (например php4 -> php5, неймспейсы) => возможно, придётся перетрахивать и ваш код
* Очень обидно, если для переопределения чего-то нельзя обойтись без патчинга фреймворка — фреймворка — а такое бывает!* «Автобусный фактор» разработки некоторых фреймворков.* Внутрикорпоративные фреймворки — фреймворки — вообще отдельная песня. С ними решение — решение — либо выводить в опенсорс, либо не особо сильно на них полагаться. Либо и то, и другое.* Единственный плюс — плюс — для слабых разработчиков фреймворк может послужить :** а) ограничителем применения бурной неокрепшей фантазии (но его нужно «правильно готовить») и ;** б) подспорьем в обучении программированию при осмотре деталей реализации самого фреймворка.
Вывод:
* Всё как обычно с любой модой/предубеждением — думайпредубеждением — «думай, прежде чем выбиратьвыбирать».* Полезное применение фреймворков шире, чем у CMS, но всё же относительно узкое.* Если фреймворк пермиссивный — пермиссивный — возможно, он хотя бы не навредит.* Главный плюс рукотворный: PHP-фреймворки — фреймворки — это мода, упрощающая продажу менеджерам, которые слышали buzzword, но не разбирались в вопросе.