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