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