Изменения

<bigstyle="color: white">''Виталий Филиппов, CUSTIS''</big>

=== {{greenmag|А потом…}} ⌘⌘ ===

=== ''Надо&nbsp;было&nbsp;{{red|думать}},&nbsp;когда&nbsp;выбирали!'' ⌘⌘ %% ===

<br /><br />…а не слепо следовать моде.<br />&nbsp;  Ибо (!) {{mag|''Ибо у каждого инструмента есть своя область применения''}} === Введение: проблема моды === Итак, о чём этот доклад? Допустим, вам нужно создать некий интернет-проект. Принципиальных возможности три: взять готовую CMS, взять фреймворк и написать проект на его основе, либо просто написать проект с нуля. Рассматривать, кстати, будем PHP, по той причине, что различных популярных CMS и фреймворков для него существует больше всего. Конечно, всё зависит от конкретного проекта, но я почти уверен, что знаю реакцию на третий вариант: «да вы что? опять создавать свой лунапарк с блэкджеком и шлюхами? всё написано до вас!» И вы склонитесь к CMS или фреймворку, почти не задумываясь о последствиях. А потом ВНЕЗАПНО пойдут жалобы (особенно в случае выбора CMS) на то, что за размещение серверов отдаётся уйма денег, сайт, несмотря на это, тормозит и не выдерживает самого банального нагрузочного тестирования, всё обрастает костылями, а подрядчики медленно внедряют доработки, которые ещё и постоянно отваливаются… А всё дело в том, что надо было думать, а не бездумно следовать моде — каждый инструмент имеет свою разумную область применения и её надо чётко понимать перед выбором. Обо всём этом и будет рассказано в докладе.

* [http://ru.wordpress.org/ WordPress] — '''был''' движком для {{greenmag|блогов}}, а стал CMS* osCommerce, Magento — {{red|спец. CMS}}, движки {{redmag|интернет-магазинов}}

==== Стандартная фраза: Теоретически… ⌘⌘ %% ====

''«…это программный комплекс...Можно любой движок сайта называть CMS, позволяющий создавать веб-сайты {{red|любого}} уровня сложности…»''<br />и лишь различать степень специализации.

[[File:Koza.svgНо обычно говорят именно о {{blue|120px]]CMS общего назначения}}.

==== Можно… Такие CMS — монстры ⌘⌘ %% ====

…Говорить и о «специализированных CMS»[[File:MutantMonster.png|180px|right]]

* {{grayred|(Сложные и вообще любой движок сайта называть CMS)Неэффективные}}* С кривой архитектурой*: Оптимизированной <s>для всего</s> {{red|ни для чего}}* С кучей лишнего функционала

Но я говорю о А оплачивать всё это {{greenred|коробочныхвам}} {{gray|(если вдруг выберете)}}, «ужеготовых» CMS.

==== Популярные CMS — монстры Оплачивать вам это… ⌘⌘ ====

* СложныеДеньгами {{green|продавцу коробки}}* НеэффективныеДеньгами {{blue|хостеру}}¹* С кривой архитектуройДеньгами {{mag|подрядчикам}} при доработках²* С кучей лишнего функционала{{mag|Репутацией}} в глазах клиентов -----<div style="color:#aaa">:¹ «Кому спам, а кому и трафик!»:² Дешёвым — обычно несколько раз</div>

Не существует универсального инструментаУниверсальные инструменты {{red|невменяемы}}!

==== Когда реально применять CMS? ⌘⌘ %% ====

<blockquote>— Где можно оправданно использовать Битрикс?<br />— В анекдотах.</blockquote> ----- {{star}} {{gray|Твит с CodeFest-2012, >200 ретвитов}} ==== Когда реально применять CMS? (а серьёзно?) ⌘⌘ ==== ;Проект {{green|простой}} ? &rArr;: CMS неудобнане нужна, ибо это {{red|слишком сложнаиз пушки по воробьям}};Проект {{greenblue|сложный}} ? &rArr;: возможностей CMS наверняка {{red|не хватит}},<br />а плохая архитектура усложнит их реализацию;Проект {{greenmag|посещаемый}} ? &rArr;: упрётесь в {{red|низкую производительность}}

'''{{gray|Серая массовка}}'''{{star}}

==== Вариант 2 (?) ⌘⌘ Хорошая цитата по поводу назначения CMS ====

А тогда {{red|<blockquote>Многие уже не надо его пускать за руль помнят, но единственное истинное предназначение CMS!}}(вроде Joomla) — предоставление не имеющему навыков в разработке пользователю возможности изменять структуру, контент и внешний вид веб-сайта. Изучать CMS можно, и даже нужно, в том случае, если Вы:

Пусть лучше заведёт:* Блог* WikiНе обладаете специальными навыками, но планируете создавать средненькие сайтики.* Группу в социальной сетиИмеете навыки, но планируете серийно окучивать не имеющих навыков заказчиков средненьких сайтиков.* {{gray|Ещё какую-нибудь хрень}}Планируете писать плагины/аддоны и т. п. с целью извлечения тонн славы и дальнейшего порабощения мира.

==== {{red|WARNING!}}К чему это я… Я это к тому, что если Вы хотите плотно сесть в тему вебдева (сделать это своим основным доходом), необходимо изучать не CMS, а сами принципы и технологии разработки.<br/blockquote> Формулировка расплывчата ⌘⌘ %% ====

[[File:Warning icon.svg==== {{mag|100px]]WARNING!}} ⌘⌘ %% ====

Поэтому если сомневаетесь — '''{{red[[File:Warning icon.svg|НЕ БЕРИТЕ CMS}}'''!100px|link=]]

Формулировка расплывчата! ==== Дайте проекту шанс<br /> вырасти большим и хорошим! ⌘⌘ ==== [[File:FunnyChick.gif|150px|left|link=]] * Если сомневаетесь в CMS — '''{{red|откажитесь}}'''!* Если вам продают сайт на CMS — '''{{red|откажитесь}}'''!{{----}} ==== При чём тут вырасти? ==== Формулировка «средненький быдлопортальчик» весьма расплывчата. Вы можете ошибиться с оценкой реального потенциала проекта — и ему потребуется расти. А доработки сайта, созданного на основе CMS, будут сильно буксовать. С ростом функционала и посещаемости рано или поздно окажется, что CMS нужно демонтировать и менять на специализированную разработку. Но к этому моменту на CMS и на её доработку уже будут затрачены немалые деньги и немалое время, а пользователи к ней привыкнут. Всё это будет сильным тормозом к её замене. Известно по опыту — заказчик нервно относится даже к рефакторингу существующей системы, и выделяет на него время только тогда, когда видит, что всё, реально ЖОПА — а до этого требует гнать доработки, внедрять «бизнес-функционал». Хотя уже год назад вам было понятно, что ЖОПА наступит, а полгода назад она на самом деле уже наступала, только до «бизнеса» это не доходило. Простой пример: многие CMS, например Magento, используют EAV «Entity-Attribute-Value» триплетное хранилище. Оно тупо загнётся, когда товаров в магазине станет много, а атрибутика усложнится. Использующая CMS контора состоит из дилетантов в любом случае — либо они не разбираются в веб-разработке и делают сайт себе, либо, что хуже, они не разбираются в разработке, но ставят на поток массовое окучивание других контор — опять-таки непрофессиональных заказчиков плохеньких сайтов. Так что, если вам продают сайт на основе CMS — отказывайтесь смело. Таким предложениям место в папке «СПАМ», с темой «бизнес-сайты за 5999 рублей» и очевидным любому человеку мнением о том, что контора — однодневка. ==== Вы спросите, а если сайт делает {{red|НЕ}}программист? ⌘⌘ ==== {{mag|Тем более не пускайте его за руль CMS!}} Пусть лучше заведёт* Блог {{gray|— ЖЖ / blogger / тематические (drive2.ru, …)}}* Wiki {{gray|(например, на wikia.com)}}* Группу в социальной сети {{green|Выхлопа будет больше}}, в том числе в плане {{blue|маркетинга}}. ==== Дополнительные проблемы ⌘⌘ ====

*: &rArr; и плачевные результаты{{red|…с плачевными результатами…}}* Закрытое ПО — Закрытая CMS — политическая проститутка*: Ибо «любой каприз {{red|«любое извращение за ваши деньги»}}* В CMS могут быть {{green|полезные идеи и фичи}}*: но зачастую они {{red|погребены}} под слоем бесполезных… ==== Подробно о дополнительных проблемах ==== Ключевым преимуществом CMS их производители обычно называют то, что сайт с их использованием создать легко, а следовательно, дёшево. Но сайты редко полностью укладываются в стандартный функционал, следовательно, к CMS нужно прикручивать доработки, силами программистов. Окей, но наша фишка — дешевизна! Значит, и доработки должны быть дешёвые. Значит, программистов надо дешёвых нанимать! А кто такие дешёвые разработческие конторы и что они наворотят? Прааавильно, вот вам и плачевный результат, тем более плачевный, чем дольше производятся доработки. «Рарус, порвали рарус!..» У закрытых, платных CMS есть ещё одна проблема — закрытая базовая система практически всегда идёт на поводу у своих клиентов, будь они внешние или внутренние, и вряд ли будут учить их жизни и запрещать им делать так, как они хотят. А клиенты CMS зачастую будут хотеть сделать какой-нибудь ужас, см. пункт 1. По поводу третьего — среди бесполезного функционала в CMS’ках встречается и полезный, но он зачастую так глубоко закопан и так усугублён кривыми архитектурными решениями, что его часто всё равно никто не использует.

Но зато мы имеем отличный пример CMS’ки с ужасной архитектуройэталонной жести, более, чем полностью, состоящей из говнокода, можем бугагагировать и рассматривать антипаттерны реализации. Итак, избранные примеры ужосов:

Конторой на флаг поднимается то, что в битриксе есть MVC. При чём тут MVC — вообще непонятно: M — модель бизнес-объектов, инкапсулирующая логику работы с оными — там полностью отсутствует. Весь «MVC» заключается в том, что код компонента разделили на два файла — компонент и шаблон. Причём несмотря на тривиальность этого разделения, среди битрикс-разработчиков находятся люди, которым оно не нравится; они изобретают (а то и находят на прострах просторах интернета) довольно популярный антипаттерн «супер компонент», то есть пустую обёртку для шаблона, и всю логику пишут прямо в шаблоне. Один такой «супер компонент», например, изобрёл некто Иван Левый. Ну да — реально левый, что с него взять.

Прикольно реализована страница ошибки 404 «страница не найдена» — если, не дай бог, она обрабатывается битриксом, там будет 300 запросов в базу, и если, не дай бог, на главной окажется размещена битая ссылка, на которую будут заходить многие пользователи — сайт уйдёт в «само-DOS» (само-отказ-в-обслуживании), ибо обработка 404 съест все ресурсы. Да и в целом, ~50 запросов на генерацию несложной страницы с включённым кэшем и 500—600 с выключенным — норма для вполне оптимизированного битрикс-сайта. Посему работа данной CMS на разделяемом хостинге обычно обречена на провал.

Это были только избранные ужасы, а в реальности их куда больше. За критикой можно отправиться хотя бы [[rupedia:1С-Битрикс|в русскую Википедию]].Кстати, там же упоминается, что никаких гарантий на работу битрикса конторка не даёт, и это чётко прописано в лицензионном соглашении. Также можно читать различные обсуждения на различных хабрах, вроде такого: http://habrahabr.ru/post/152173/

==== Зато ''«мы стали более лучше одеваться!»''{{star}} ⌘⌘ ====

{{star}} …''«Овощи там, рожь!» &copy; '' © Света из Иваново

==== Битрикс — не единственный пример проблем ⌘⌘ ==== '''УЖАСНЫЙ''' пример. Но не единственный. <div style="float: right; font-size: 600%; color: red">☹</div>* Любые движки с EAV, например:** {{mag|Magento}}** {{blue|WordPress}}* {{gray|Да и прочие CMS не блещут}} …но они хотя бы Open Source. ==== Проблемными являются почти все CMS ==== Битрикс, конечно, пример вполне себе ужасный, и ужасный главным образом из-за успешного маркетинга. Не будь маркетинга, он бы существовал на уровне слабоизвестного поделия и не резал бы глаза. Но благодаря маркетингу и политике «партнёрства», увы, он проник в кучу проектов, и создаёт множество проблем. Всю ту же ругань можно адресовать и к прочим general-purpose CMS, к тем же WordPress, Joomla, специфичным Magento и osCommerce — с их смесью вёрстки и кода и EAV-хранилищем, которому грустно живётся при условии сложной атрибутики и большой посещаемости… И использовать их в серьёзном проекте — это так же курам на смех. Но у этих CMS есть одно большое оправдание: они '''БЕСПЛАТНЫ'''. Причём — не просто бесплатны, а '''СВОБОДНЫ'''. А битрикс — это закрытая, платная, недешёвая вещь в себе, имеющая, тем не менее, либо худшее, либо по меньшей мере сравнимое с ними качество. === Фреймворки === ==== Фреймворки (PHP) ⌘⌘ %% ==== ОК, CMS не берём.

Но PHP-фреймворки-то чем не угодили? == Мысли ==Для начала: что такое фреймворк? ⌘⌘ %% ==== Как и библиотека, это {{mag|некий набор подключаемого функционала}}* -----<nowiki>*</nowiki> {{gray|''набор, но не простой''}} ==== Разница в повсеместной инверсии управления ⌘⌘ %% ==== [[File:FW-Lib-IoC.svg|500px|link=]] ==== Определение фреймворка ==== ''Фреймворки'', в принципе, очень похожи на ''библиотеки'', и также являют собой некий набор заранее реализованного функционала, который можно подключить к вашей программе. Бывает, что эти понятия даже смешиваются, и какой-нибудь Qt называют то фреймворком, то библиотекой. Однако есть вполне явное различие — ''повсеместная инверсия управления'' (не каноничный IoC, а инверсия в широком смысле): * (Прямое управление) Ваш код запускается, а когда ему нужно — вызывает функции библиотеки.* (Обратное управление) Запускается сначала фреймворк, и ваш код вызывает тоже он — тогда, когда нужно ему. Естественно, все эти ''«когда нужно ему»'' задокументированы и при написании кода вы крепите свои методы/классы на выбранные точки расширения. Фактически, фреймворк — это в широком смысле «базовый класс» приложения — вы можете от него унаследоваться и переопредить часть его логики — но обычно нельзя переопредить всю, не демонтируя сам фреймворк. Примеры PHP-фреймворков: Zend Framework, Code Igniter, Yii, Kohana, onPHP. === Состав фреймворков === ==== Фреймворки и паттерны ⌘⌘ ==== [[File:Warning icon.svg|50px|left]] Полезно ли возводить ''в абсолют''<br /> {{green|паттерны проектирования}}? {{red|Ой не факт!}} <blockquote><small>''«You have a Problem and decide to use Java. Now you have Problem, ProblemImpl, ProblemException and ProblemFactory.»''</small></blockquote> <blockquote><small>Хабр: [http://habrahabr.ru/post/141477/ Все используют единую фабрику фабрик фабрик инструментов всякий раз, когда им нужен молоток?…]</small></blockquote> ==== Проблема — Over-Engineering ⌘⌘ ==== Или же, стремление всё {{red|чрезмерно обобщить}}. * {{red|☹}} Лишние слои абстракций* {{red|☹}} «Введение в конфиги всем.ру, том 2»* {{red|☹}} Раннее внедрение излишней расширяемости Истинное удобство расширения: {{mag|KISS, YAGNI}}{{star}} -----{{star}} {{gray|Keep It Simply Stupid, You Ain't Gonna Need It.}} ==== Шаблоны проектирования ==== Фреймворк — это не только и не столько функционал. Фреймворк также более или менее жёстко привязывает разработку и проектирование к каким-либо шаблонам. Шаблоны эти обычно не взяты с неба, а достаточно распространены и признаны, но это не отменяет то, что какие-то из них более применимы для определённых задач, а какие-то — менее. В то же время разрабатывать с использованием фреймворка и игнорировать паттерны, в нём заложенные — обычно либо неудобно, либо вообще невозможно. Это-то и приводит к шуткам о «фабриках проблем» и «фабрикам фабрик фабрик инструментов». Слепое принятие паттернов может быть полезно разве что для обучения начинающих разработчиков — пусть лучше они научатся паттернам, чем написанию битриксоподобных портянок. Возможно, проблема не в самих фреймворках, а в чрезмерной технологизации (Over-Engineering’е) — имеется ввиду, когда создатель системы, вместо простой реализации нужного функционала в соответствии с принципами [[rupedia:KISS_(принцип)|KISS]] (Keep It Simply Stupid) и [[rupedia:Принцип YAGNI|YAGNI]] (You Ain’t Gonna Need It), сразу начинает чрезмерно его обобщать и закладывать ненужные точки расширения, результатом чего типично являются:* Лишние слои абстракции, в лучшем случае — просто лишние, а в худшем — ограничивающие и делающие неоптимальным использование нижележащих API.* Отсутствие точек расширения в нужных местах и наличие в ненужных.* Вынесение в конфигурацию ВСЕГО, чрезмерное обобщение и как итог — сложные (доменно-специфичные) языки конфигурации и описания функционала. Мем «введение в конфиги всем.ру, том 2» — когда я работал в Агаве над vsem.ru, конфиги там занимали около 470 килобайт и 12000 строк. ==== Фреймворки и SAPI ⌘⌘ %% ==== [[File:OtherWebNoAPI.svg|90px|left]][[File:PHP-SAPI.svg|120px|right]] <small>Серверов&nbsp;много,&nbsp;API&nbsp;тоже<br />{{gray|(модуль/CGI/SCGI/FastCGI/…)}}</small> <small>{{mag|Нет стандарта? &rArr; рождается обёртка}}<br />Но в PHP SAPI {{green|уже есть!}} Весьма полное, пусть и процедурное.</small> {{----}} ==== Фреймворки и функционал ⌘⌘ ==== Типичные вещи: шаблоны, интерфейс БД, сессии, загрузка файлов, SOAP… * В языках общего назначения их нет.*: {{green|✓ Тема для фреймворка.}}* Но в PHP есть почти всё*: {{red|× Фреймворк добавляет мало функционала.}} ==== О полноте PHP и слабой нужде во фреймворках ==== Одна из причин, по которой (в других языках) возникают фреймворки — это отсутствие API взаимодействия с веб-сервером, и широкого класса базового функционала, нужного для веб-разработки. Запрос от клиента поступает к веб-серверу, который должен его в каком-то виде передать в приложение. Вид передачи называется серверным API (SAPI), и в нём уже возникает фреймворкоподобная «инверсия управления» — не ваше приложение вызывает веб-сервер, а веб-сервер вызывает приложение. Когда SAPI становится несколько, появляется нужда в абстракции — и это первая точка зарождения фреймворка. Дальше он дополняется тем типичным функционалом, которого так не хватает в языке — и вуаля, фреймворк готов! Простейшие примеры — Perl и Java. Веб начинался с перла и CGI, и PHP в шутку называют «Pa`am Hayiti Perl», что в переводе с иврита означает «когда-то я был Перлом», однако за всё время в Перле так и не появилось стандартного SAPI. Есть CGI, но он неполон — например, для обработки загрузок файлов нужен дополнительный обработчик. Есть и другие API, я их даже рассматривал в своей вики — [[Платформы для запуска Perl веб-приложений]], но стандарта всё равно нет. По поводу библиотек — хотя у Перла есть офигенный плюс — CPAN, на котором лежит куча библиотек почти под все нужды, которые можно поставить одной командой — удивительно, но на всём CPAN’е ''нет нормального SOAP-клиента!'' (все они так или иначе ограничены в возможностях) А в PHP SOAP-клиент, да и стандартное SAPI, и вообще почти всё остальное, встроено прямо в интерпретатор! В виде модулей. Да, это, может, и не очень красиво, зато очень удобно — не надо тащить 100500 зависимостей с CPAN’а, а поставил три с половиной модуля и всё уже работает. Тем более, что обычно почти все модули уже стоят. Причём, встроен весь этот функционал в PHP максимально просто (полный KISS), поэтому и вопросов по использованию никаких не возникает. Ну и что, что глобальный неймспейс закидан функциями по самое не горюй? Кушать же они не просят. Поэтому такой путь зарождения фреймворка в PHP «не катит». И поэтому же сам PHP популярен — его очень легко поддерживать. ==== Что же остаётся PHP-фреймворкам? ⌘⌘ ==== <big>Ответ: '''{{mag|ОБЁРТКИ!}}'''</big> * {{red|Для всего!}} {{gray|иногда в несколько слоёв.}}* Бывают {{red|жёсткие}}, неизменяемые без патчинга.* Кроме обёрток — лишь {{green|мелкие полезные фичи}}. === Минусы и плюсы фреймворков === ==== Кроме того ⌘⌘ ==== [[File:Bus factor.svg|150px|right]] {{red|Фреймворк — жирная зависимость!}} : {{mag|&rArr;}} Для библиотек не подходит: {{mag|&rArr;}} Доп. источник багов и дыр: {{mag|&rArr;}} Проблемы глобальных обновлений: {{mag|&rArr;}} «Автобусный фактор» ==== Область применения фреймворков ⌘⌘ ==== * Проект простой? {{red|× Усложнит реализацию.}}* Проект сложный? {{red|× Много уникального прикрутится сбоку.}}** Библиотека? {{red|× Ограничит использование.}}* {{green|Проекты, где много однотипного функционала.}}*: {{green|✓ Подходит!}} {{mag|и это сильно шире, чем у CMS.}} -----<nowiki>*</nowiki> {{gray|Гибкий (пермиссивный) фреймворк хотя бы не навредит.}} ==== Плюсы фреймворков ⌘⌘ ==== * Плюс для продажи {{green|поддавшимся моде}} менеджерам* Для начинающих разработчиков** {{mag|Ограничитель}} применения бурной неокрепшей фантазии{{star}}** Подспорье в {{green|обучении}} -----{{star}} {{gray|если фреймворк готовить по канонам.}} ==== О прочих плюсах и минусах фреймворков ==== Для простых проектов минус фреймворка — усложнение: время на изначальное внедрение фреймворка может быть сопоставимо со временем реализации всего проекта ''без'' фреймворка. Для сложных проектов минус фреймворка — обязательно наличие непереопределяемого функционала: наверняка чего-то не хватит. Для библиотек минус фреймворка — то, что он является очень жирной зависимостью и фактически превращает библиотеку в собственный плагин, который отдельно использовать нельзя. Жирная зависимость — на самом деле минус для любого проекта. Вот первые пришедшие на ум три причины, почему:* Фреймворки тоже пишут люди, которые тоже делают ошибки. Любая зависимость — это потенциальный источник багов и дыр безопасности.* У некоторых фреймворков маленький «автобусный фактор», то есть количество его разработчиков, которое может сбить автобус без угрозы серьёзных проблем для проекта. Завися от такого фреймворка, вы зависите и от тех самых ключевых сторонних персон.* Фреймворк не стоит на месте — его нужно обновлять. Это не минус до тех пор, пока команда проекта не решит полностью переписать фреймворк и сделать его несовместимым с прежней версией. Практика показывает, что это вполне происходит — вот недавно зарелизился Zend Framework 2.0, который «will look alien to you if you’ve worked significantly with ZF1». У фреймворков, конечно, есть и плюсы. Главный из них «рукотворный» — приложение, написанное на основе фреймворка, удобно продавать поддавшимся моде менеджерам и/или поддавшимся моде клиентам («фэйшн», как говорит наш сотрудник Коля Гребнев). Учитывая то, что мода на PHP-фреймворки пришла не так давно, приесться она ещё не успела, поэтому… оно работает. Второй плюс работает, только если фреймворк «готовить» по всем канонам, не разламывая его вдребезги и следуя заложенным в него шаблонам разработки: фреймворк будет ограничивать фантазию разработчиков. Хорошо это или плохо? Ну, в случае, если ваши разработчики — неокрепшие начинающие умы, тогда, наверное, хорошо: может быть, принятые во фреймворке практики неидеальны, но зато ваши junior’ы по крайней мере не натворят совсем паршивых дел. В то же время — если ваши разработчики сильны, «ограничивать их фантазию» может означать «ограничивать их потенциал», а это уже не очень хорошо. Ну и, конечно, плюс в обучении — ясно, что разглядывание деталей реализации фреймворка и критическая оценка тех самых заложенных в него практик идёт на пользу всем. Никому не будет лишним узнать ещё одну технологию, а в общемировом плане — пусть лучше начинающие программисты изучают фреймворки, чем CMS — в отличие от CMS, код фреймворков обычно вменяем, да и о «паттернах» и прочей лабуде начинающие узнают быстрее. ==== Закрытые, внутренние, малопопулярные фреймворки ⌘⌘ ==== Имеют дополнительные минусы:* {{red|☹}} Плохая документация {{gray|(а то и отсутствие)}}* {{red|☹}} Странные практики {{gray|(PHP Jihad, алиментщик)}}* {{red|☹}} Политическая проституция {{gray|(закрытые, внутренние)}}* {{red|☹}} Невозможность переопределения ==== Внутренние фреймворки — отдельная песня ⌘⌘ ==== * ☹ Нуждаются в {{red|поддержке}}* ☹ Слабо конкурируют с {{green|mainstream}}* <big>☠</big> {{red|Склонны к умиранию}} Отсюда выводы:* Либо {{mag|OpenSource}}, либо {{red|не полагаться}} на них* [[File:Warning icon.svg|30px]] Обязательно делать {{green|пермиссивными}}, а не жёсткими ==== О внутренних фреймворках ==== В рамках любого растущего коллектива программистов часто зарождаются собственные практики, а за ними библиотеки/фреймворки. Ничего плохого в этом нет, по крайней мере, до тех пор, пока зародившееся не принимается всей компанией за «технологические рельсы», на которых должны разрабатываться все новые проекты. Тут дело в том, что зарождающиеся практики вовсе не уникальны, и у многих других людей в мире возникают те же мысли. Следовательно, даже если ничего подобного до сих пор не было — оно с большой вероятностью может появиться и стать каким-нибудь OpenSource’ным, популярным, мэйнстримовым. А дальше сказывается ограниченность внутренних ресурсов по сравнению с внешними: внутренние силы — это обычно максимум один отдел, внешние — обычно либо компания, занимающаяся только этим фреймворком, либо большая корпорация, просто выделяющая на него много ресурсов, либо вообще '''сообщество''', имеющее неограниченные тестеро-оценочные возможности. И если внешний фреймворк — не полное говно, то внутреннему с ним обычно конкурировать тяжело — функционал начинает отствать, документация устаревать, а сотрудники жаловаться на «кривые технологические рельсы», которые слишком ограничивают разработку. А это начало конца! Отсюда можно сделать следующие выводы:* Внутренние фреймворки должны быть максимально гибкими, чтобы уметь нормально сосуществовать с внешними, если такое понадобится.* Для защиты от умирания фреймворк нужно пытаться выводить в OpenSource — это самый простой путь к популярности (при этом не такой простой сам по себе). Логично — если это пытаться ещё и продавать, оно вообще никому нужно не будет. А сообщество может подсказать правильный путь развития. === Выводы ⌘⌘ === * Не поддавайтесь моде! {{mag|''Каждый инструмент имеет свою область применения!''}}* Удел применения CMS — {{red|быдлосайтики.}}* Удел фреймворков — {{blue|средние по сложности проекты}}{{gray| (+ продажа «модникам»).}}* Плохо ли, что они есть? Да нет. {{green|Природа любит разнообразие.}}

Что такое CMS?* Движок, на котором «можно сделать всё», причём в идеале «без единого гвоздя» E-mail:)* Смысл именно в спозиционированной общности применения[[File:Myemail2.* Скажем, MediaWiki — не CMS, хотя сайт на ней сделать тоже можно. WordPress — когда-то тоже не был CMS, а сейчас уподобился битриксуpng|link=http://yourcmc.ru/wiki/User:VitaliyFilippov]]

Минусы CMSНаши OpenSource проекты:* Монстр — Сложная и Неэффективная** => Плохо подходит для посещаемых сайтов**: И посещаемый сайт сделать на CMS можно, но геморроя не оберёшься. Будут тормоза, будет дорогой хостинг, будут простои, будут падения при внесении доработок и даже, например, сбросе кэша.** Фредерик П. Брукс, "Мифический человеко-месяц или как создаются программные системы": сложность программной системы растет нелинейно при увеличении размера => отсюда все эти SOA и т. п.* И вы оплачиваете её неэффективность!** Деньгами хостингу серверов.** Деньгами продавцу коробки.** Деньгами подрядчикам, её дорабатывающим.**: Дешёвым — обычно несколько раз* Некрасивая архитектура, оптимизированная под «общий случай». То есть, не оптимизированная ни подо что вообще.** Простейший пример — EAV<ref>Она же OAV (object-attribute-value), фреймворки неэффективно обеспечивающие работу с произвольными атрибутными сущностями.</ref>.* Расчёт на доработку дешёвыми подрядчиками (и, похоже, дешёвыми программистами самой CMS)** Как они там в битриксе параметры научиться экранировать не могут.** Нормальный, уважающий себя, разработчик в ЭТО потом вообще не полезет.* Вы оплачиваете и её сложность!** * +++ Проституточная суть платного/закрытого.* Зачастую полезный функционал погребён под бесполезным и усугублён кривыми архитектурными решениями* Примеры:** Битрикс (должен быть стоп-словом)*** «БИТРИКС ДЕТЕКТЕД» — вполне катит для отдельного раздела на говнокод.ру.*** Битрикс можно снести с серверов, но нельзя убрать из головы.***: («Можно вывезти девушку из деревни, но нельзя вывести деревню из девушки»).** WordPress — внутри тот же битрикс, только открытый и менее коробочный.** Любые движки интернет-магазинов с EAV.** http://ru-anticms.livejournal.com/3931.html** http://ru-anticmswiki.livejournal4intra.comnet/

Что такое фреймворк?* Как и библиотека, набор заранее написанного функционала…* Но фреймворк отличается от библиотеки повсеместным применением IoC{{blue|$this}} = http://yourcmc.ru/wiki/CMS-Frameworks

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

Вывод* Общность — ЛЕНЬ, вечное желание получить результат, ничего не делая.* http://ru-anticms.livejournal.com/3931.html* Всё как обычно с любой модойhttp:/предубеждением — «думай, прежде чем выбирать»/www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html* Полезное Неправильное применение фреймворков ширепортит даже неплохой в целом инструмент. Пример — OpenX предназначен для организации небольшой «баннерной сети», чем у CMSа, но всё же относительно узкое.* Если фреймворк пермиссивный — возможнонапример, он хотя бы не навредитдля показа 5 баннеров на сайте.