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

Материал из YourcmcWiki
Перейти к: навигация, поиск
м
м
Строка 1: Строка 1:
 
Название доклада:
 
Название доклада:
* «Мода на коробки и фреймворки в вебе — доколе?»
+
* «Мода на коробки и фреймворки в вебе — доколе?»
  
 
Тезисы:
 
Тезисы:
Строка 6: Строка 6:
 
* Как часто для разработки веб-проекта (не самого простого!) выбирается коробочная CMS, а потом, пока программисты яростно пытаются совладать с её недостатками, а за хостинг каждый месяц отстегиваются миллионы, менеджеры, несмотря ни на что, продолжают защищать свой выбор, аргументируя это тем, что «инструмент отличный» и его всего-то надо «немного подкрутить, и цель точно будет достигнута»?
 
* Как часто для разработки веб-проекта (не самого простого!) выбирается коробочная CMS, а потом, пока программисты яростно пытаются совладать с её недостатками, а за хостинг каждый месяц отстегиваются миллионы, менеджеры, несмотря ни на что, продолжают защищать свой выбор, аргументируя это тем, что «инструмент отличный» и его всего-то надо «немного подкрутить, и цель точно будет достигнута»?
 
* А как часто выбирается жирный фреймворк (что, конечно, лучше CMS), который сразу начинает неудержимо обрастать костылями, потому что цели, под которые он разрабатывался, не совсем соответствуют целям проекта?
 
* А как часто выбирается жирный фреймворк (что, конечно, лучше CMS), который сразу начинает неудержимо обрастать костылями, потому что цели, под которые он разрабатывался, не совсем соответствуют целям проекта?
* Что общего в этих подходах? Во-первых, оба подхода рождаются из одного желания — желания создать (а зачастую и продавать!) продукт, который Вроде-Бы может решить… абсолютно ВСЕ задачи. А во-вторых, и то, и другое настолько «вошло в моду», что люди почти не задумываются о куче проблем, которые получат с выбором таких инструментов.
+
* Что общего в этих подходах? Во-первых, оба подхода рождаются из одного желания — желания создать (а зачастую и продавать!) продукт, который Вроде-Бы может решить… абсолютно ВСЕ задачи. А во-вторых, и то, и другое настолько «вошло в моду», что люди почти не задумываются о куче проблем, которые получат с выбором таких инструментов.
 
* Соображения именно об этой моде и о типичных проблемах, получаемых людьми вместе с ней, и хотелось бы донести в рамках доклада.
 
* Соображения именно об этой моде и о типичных проблемах, получаемых людьми вместе с ней, и хотелось бы донести в рамках доклада.
  
Строка 12: Строка 12:
 
* Движок, на котором «можно сделать всё», причём в идеале «без единого гвоздя» :)
 
* Движок, на котором «можно сделать всё», причём в идеале «без единого гвоздя» :)
 
* Смысл именно в спозиционированной общности применения.
 
* Смысл именно в спозиционированной общности применения.
* Скажем, MediaWiki — не CMS, хотя сайт на ней сделать тоже можно. WordPress — когда-то тоже не был CMS, а сейчас уподобился битриксу.
+
* Скажем, MediaWiki — не CMS, хотя сайт на ней сделать тоже можно. WordPress — когда-то тоже не был CMS, а сейчас уподобился битриксу.
  
 
Минусы CMS:
 
Минусы CMS:
* Монстр — Сложная и Неэффективная
+
* Монстр — Сложная и Неэффективная
 
** => Плохо подходит для посещаемых сайтов
 
** => Плохо подходит для посещаемых сайтов
 
**: И посещаемый сайт сделать на CMS можно, но геморроя не оберёшься. Будут тормоза, будет дорогой хостинг, будут простои, будут падения при внесении доработок и даже, например, сбросе кэша.
 
**: И посещаемый сайт сделать на CMS можно, но геморроя не оберёшься. Будут тормоза, будет дорогой хостинг, будут простои, будут падения при внесении доработок и даже, например, сбросе кэша.
** Сложность программной системы растет нелинейно при увеличении размера => отсюда все эти SOA и т. п.
+
** Сложность программной системы растет нелинейно при увеличении размера => отсюда все эти SOA и т. п.
 
* И вы оплачиваете её неэффективность!
 
* И вы оплачиваете её неэффективность!
 
** Деньгами хостингу серверов.
 
** Деньгами хостингу серверов.
 
** Деньгами продавцу коробки.
 
** Деньгами продавцу коробки.
 
** Деньгами подрядчикам, её дорабатывающим.
 
** Деньгами подрядчикам, её дорабатывающим.
**: Дешёвым — обычно несколько раз
+
**: Дешёвым — обычно несколько раз
 
* Некрасивая архитектура, оптимизированная под «общий случай». То есть, не оптимизированная ни подо что вообще.
 
* Некрасивая архитектура, оптимизированная под «общий случай». То есть, не оптимизированная ни подо что вообще.
** Простейший пример — EAV<ref>Она же OAV (object–attribute–value), фреймворки неэффективно обеспечивающие работу с произвольными атрибутными сущностями.</ref>.
+
** Простейший пример — EAV<ref>Она же OAV (object-attribute-value), фреймворки неэффективно обеспечивающие работу с произвольными атрибутными сущностями.</ref>.
 
* Расчёт на доработку дешёвыми подрядчиками (и, похоже, дешёвыми программистами самой CMS)
 
* Расчёт на доработку дешёвыми подрядчиками (и, похоже, дешёвыми программистами самой CMS)
 
** Как они там в битриксе параметры научиться экранировать не могут.
 
** Как они там в битриксе параметры научиться экранировать не могут.
Строка 34: Строка 34:
 
* Примеры:
 
* Примеры:
 
** Битрикс (должен быть стоп-словом)
 
** Битрикс (должен быть стоп-словом)
*** «БИТРИКС ДЕТЕКТЕД» — вполне катит для отдельного раздела на говнокод.ру.
+
*** «БИТРИКС ДЕТЕКТЕД» — вполне катит для отдельного раздела на говнокод.ру.
 
*** Битрикс можно снести с серверов, но нельзя убрать из головы.
 
*** Битрикс можно снести с серверов, но нельзя убрать из головы.
 
***: («Можно вывезти девушку из деревни, но нельзя вывести деревню из девушки»).
 
***: («Можно вывезти девушку из деревни, но нельзя вывести деревню из девушки»).
** WordPress — внутри тот же битрикс, только открытый и менее коробочный.
+
** WordPress — внутри тот же битрикс, только открытый и менее коробочный.
 
** Любые движки интернет-магазинов с EAV.
 
** Любые движки интернет-магазинов с EAV.
  
Строка 50: Строка 50:
 
** If you have a Problem and decide to use Java, now you have Problem, ProblemImpl, ProblemException and ProblemFactory.
 
** If you have a Problem and decide to use Java, now you have Problem, ProblemImpl, ProblemException and ProblemFactory.
 
** http://habrahabr.ru/post/141477/
 
** http://habrahabr.ru/post/141477/
* Жирная зависимость => для библиотек не подходит. Библиотека под фреймворк — уже не библиотека, а плагин.
+
* Жирная зависимость => для библиотек не подходит. Библиотека под фреймворк — уже не библиотека, а плагин.
 
* Простые проекты усложняет => для простого не подходит.
 
* Простые проекты усложняет => для простого не подходит.
 
* В сложных проектах жмёт => для сложного тоже не подходит.
 
* В сложных проектах жмёт => для сложного тоже не подходит.
Строка 58: Строка 58:
 
* Дополнительный источник багов и дыр.
 
* Дополнительный источник багов и дыр.
 
* Глобальные перетрахивания фреймворка, происходящие при обновлении языка (например php4 -> php5, неймспейсы) => возможно, придётся перетрахивать и ваш код
 
* Глобальные перетрахивания фреймворка, происходящие при обновлении языка (например php4 -> php5, неймспейсы) => возможно, придётся перетрахивать и ваш код
* Очень обидно, если для переопределения чего-то нельзя обойтись без патчинга фреймворка — а такое бывает!
+
* Очень обидно, если для переопределения чего-то нельзя обойтись без патчинга фреймворка — а такое бывает!
 
* «Автобусный фактор» разработки некоторых фреймворков.
 
* «Автобусный фактор» разработки некоторых фреймворков.
* Внутрикорпоративные фреймворки — вообще отдельная песня. С ними решение — либо выводить в опенсорс, либо не особо сильно на них полагаться. Либо и то, и другое.
+
* Внутрикорпоративные фреймворки — вообще отдельная песня. С ними решение — либо выводить в опенсорс, либо не особо сильно на них полагаться. Либо и то, и другое.
* Единственный плюс — для слабых разработчиков фреймворк может послужить:
+
** Алиментщик, PHP Jihad, «не дай бог join в коде увижу!»
 +
* Единственный плюс — для слабых разработчиков фреймворк может послужить:
 
** а) ограничителем применения бурной неокрепшей фантазии (но его нужно «правильно готовить»);
 
** а) ограничителем применения бурной неокрепшей фантазии (но его нужно «правильно готовить»);
 
** б) подспорьем в обучении программированию при осмотре деталей реализации самого фреймворка.
 
** б) подспорьем в обучении программированию при осмотре деталей реализации самого фреймворка.
  
 
Вывод:
 
Вывод:
* Всё как обычно с любой модой/предубеждением — «думай, прежде чем выбирать».
+
* Всё как обычно с любой модой/предубеждением — «думай, прежде чем выбирать».
 
* Полезное применение фреймворков шире, чем у CMS, но всё же относительно узкое.
 
* Полезное применение фреймворков шире, чем у CMS, но всё же относительно узкое.
* Если фреймворк пермиссивный — возможно, он хотя бы не навредит.
+
* Если фреймворк пермиссивный — возможно, он хотя бы не навредит.
* Главный плюс рукотворный: PHP-фреймворки — это мода, упрощающая продажу менеджерам, которые слышали buzzword, но не разбирались в вопросе.
+
* Главный плюс рукотворный: PHP-фреймворки — это мода, упрощающая продажу менеджерам, которые слышали buzzword, но не разбирались в вопросе.

Версия 01:22, 11 сентября 2012

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

  • «Мода на коробки и фреймворки в вебе — доколе?»

Тезисы:

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

Что такое CMS?

  • Движок, на котором «можно сделать всё», причём в идеале «без единого гвоздя» :)
  • Смысл именно в спозиционированной общности применения.
  • Скажем, MediaWiki — не CMS, хотя сайт на ней сделать тоже можно. WordPress — когда-то тоже не был CMS, а сейчас уподобился битриксу.

Минусы CMS:

  • Монстр — Сложная и Неэффективная
    • => Плохо подходит для посещаемых сайтов
      И посещаемый сайт сделать на CMS можно, но геморроя не оберёшься. Будут тормоза, будет дорогой хостинг, будут простои, будут падения при внесении доработок и даже, например, сбросе кэша.
    • Сложность программной системы растет нелинейно при увеличении размера => отсюда все эти SOA и т. п.
  • И вы оплачиваете её неэффективность!
    • Деньгами хостингу серверов.
    • Деньгами продавцу коробки.
    • Деньгами подрядчикам, её дорабатывающим.
      Дешёвым — обычно несколько раз
  • Некрасивая архитектура, оптимизированная под «общий случай». То есть, не оптимизированная ни подо что вообще.
    • Простейший пример — EAV[1].
  • Расчёт на доработку дешёвыми подрядчиками (и, похоже, дешёвыми программистами самой CMS)
    • Как они там в битриксе параметры научиться экранировать не могут.
    • Нормальный, уважающий себя, разработчик в ЭТО потом вообще не полезет.
  • Вы оплачиваете и её сложность!
  • Зачастую полезный функционал погребён под бесполезным и усугублён кривыми архитектурными решениями
  • Примеры:
    • Битрикс (должен быть стоп-словом)
      • «БИТРИКС ДЕТЕКТЕД» — вполне катит для отдельного раздела на говнокод.ру.
      • Битрикс можно снести с серверов, но нельзя убрать из головы.
        («Можно вывезти девушку из деревни, но нельзя вывести деревню из девушки»).
    • WordPress — внутри тот же битрикс, только открытый и менее коробочный.
    • Любые движки интернет-магазинов с EAV.

Что такое фреймворк?

  • Как и библиотека, набор заранее написанного функционала…
  • Но фреймворк отличается от библиотеки повсеместным применением 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 в коде увижу!»
  • Единственный плюс — для слабых разработчиков фреймворк может послужить:
    • а) ограничителем применения бурной неокрепшей фантазии (но его нужно «правильно готовить»);
    • б) подспорьем в обучении программированию при осмотре деталей реализации самого фреймворка.

Вывод:

  • Всё как обычно с любой модой/предубеждением — «думай, прежде чем выбирать».
  • Полезное применение фреймворков шире, чем у CMS, но всё же относительно узкое.
  • Если фреймворк пермиссивный — возможно, он хотя бы не навредит.
  • Главный плюс рукотворный: PHP-фреймворки — это мода, упрощающая продажу менеджерам, которые слышали buzzword, но не разбирались в вопросе.
  • Она же OAV (object-attribute-value), фреймворки неэффективно обеспечивающие работу с произвольными атрибутными сущностями.