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