Изменения
→⌘⌘ %%
[[File:Monster-shadow-cms.svg|470px|link=]]
<bigstyle="color: white">''Виталий Филиппов, CUSTIS''</big>
=== Допустим, вам нужно создать интернет-проект ⌘⌘ %% ===
* А также куча {{green|модных фреймворков!}} Zend, CI, Yii! Паттерны, все и разом!
=== {{greenmag|А потом…}} ⌘⌘ ===
[[File:CryingFace.svg|200px|right]]
{{red|''«Нет, надо ещё чуть-чуть докрутить, и цель будет достигнута!»''}}
=== ''Надо было {{red|думать}}, когда выбирали!'' ⌘⌘ %% ===
=== CMS ===
[[File:CMS2.png|200px|link=]]
-----
{{star}} Just for Lulz: http://lurkmore.to/CMS
==== Что такое CMS? ⌘⌘ ====
:: <span style="font-size: 300%; color: red">;-)</span>
==== Смысл именно в общности применения ⌘⌘ Определение CMS ====
CMS — это «Система Управления Контентом» сайта. Кто-то может понимать под этим вообще любой движок любого веб-приложения, но обычно, говоря «CMS», имеют ввиду CMS «общего назначения», не заточенные на решение одной конкретной задачи. Например,баг-трекеры (Bugzilla, Jira, Mantis, Trac), хотя и имеют какого-то вида возможности динамического управления содержимым, никому не приходит в голову называть CMS’ками.
==== Стандартная фраза: ⌘⌘ %% ====
[[File:Koza.svg|120px]]
==== Можно… Смысл именно в общности применения ⌘⌘ %% ====
* [http://www.mediawiki.org/ MediaWiki], [http://moinmo.in/ MoinMoin] и т. п. — не CMS, а {{green|вики-движки}} {{gray|(и вообще любой движок сайта называть CMSхотя сайт на них сделать можно)}}* [http://phpbb.net/ PhpBB], [http://www.invisionpower.com/ IPB] — движки {{green|форумов}}
* [http://ru.wordpress.org/ WordPress] — '''был''' движком для {{mag|блогов}}, а стал CMS* osCommerce, Magento — {{red|спец. CMS}}, движки {{mag|интернет-магазинов}}* Joomla, Drupal, MODx, NetCat, Битрикс, UMI.CMS — {{red|это всё CMS}} ==== Теоретически… ⌘⌘ %% ==== ...Можно любой движок сайта называть CMS,<br />и лишь различать степень специализации. Но обычно говорят именно о {{blue|CMS общего назначения}}. ==== Такие CMS — это монстры ⌘⌘ ==== [[File:MutantMonster.png|180px|right]]
* {{red|Сложные и Неэффективные}}
* С кривой архитектурой
*: Оптимизированной <s>для всего</s> {{red|ни для чего}}
* С кучей лишнего функционала
А оплачивать всё это {{red|вам}} {{gray|(если вдруг выберете)}}
==== Оплачивать вам это… ⌘⌘ ====
* Деньгами {{green|продавцу коробки}}
* Деньгами {{blue|хостеру}}<sup>1</sup>
* Деньгами {{mag|подрядчикам}} при доработках<sup>2</sup>
* {{mag|Репутацией}} в глазах клиентов
-----
<div style="color:#aaa">
:<sup>1</sup> «Кому спам, а кому и трафик!»
:<sup>2</sup> Дешёвым — обычно несколько раз
</div>
==== А всё дело в том, что… ⌘⌘ %% ====
[[File:Wenger_giant_knife.png|300px|link=http://www.wengerna.com/giant-knife-16999]]
==== Когда реально применять CMS? ⌘⌘ ====
;Проект {{green|простой}} ? ⇒: CMS неудобнане нужна, ибо это {{red|слишком сложнаиз пушки по воробьям}};Проект {{greenblue|сложный}} ? ⇒: возможностей CMS наверняка {{red|не хватит}},<br />а плохая архитектура усложнит их реализацию;Проект {{greenmag|посещаемый}} ? ⇒: упрётесь в {{red|низкую производительность}}
==== Что же остаётся? ⌘⌘ ====
'''{{gray|Серая массовка}}'''{{star}}
* Шаблонные,
{{star}} {{gray|Какие-нибудь «порталы» с копи-пи**ерами новостей…}}
==== {{red|WARNING!}}<br/> Формулировка расплывчата ⌘⌘ %% Хорошая цитата по поводу назначения CMS ====
[[Filehttp:Warning icon//forum.svg|100px]searchengines.ru/archive/index.php/t-394432.html Отсюда]
==== Вы спросите, а если сайт делает {{red|НЕ}}программист? ⌘⌘ ====
Пусть лучше заведёт
* Расчёт на доработку дешёвым ресурсом
*: {{red|с …с плачевными результатамирезультатами…}}
* Закрытая CMS — политическая проститутка
*: {{red|«любое извращение за ваши деньги»}}
* В CMS могут быть {{green|полезные идеи и фичи}}
*: но зачастую они {{red|погребены}} под слоем бесполезных…
==== Подробно о дополнительных проблемах ====
Ключевым преимуществом CMS их производители обычно называют то, что сайт с их использованием создать легко, а следовательно, дёшево. Но сайты редко полностью укладываются в стандартный функционал, следовательно, к CMS нужно прикручивать доработки, силами программистов. Окей, но наша фишка — дешевизна! Значит, и доработки должны быть дешёвые. Значит, программистов надо дешёвых нанимать! А кто такие дешёвые разработческие конторы и что они наворотят? Прааавильно, вот вам и плачевный результат, тем более плачевный, чем дольше производятся доработки. «Рарус, порвали рарус!..»
У закрытых, платных CMS есть ещё одна проблема — закрытая базовая система практически всегда идёт на поводу у своих клиентов, будь они внешние или внутренние, и вряд ли будут учить их жизни и запрещать им делать так, как они хотят. А клиенты CMS зачастую будут хотеть сделать какой-нибудь ужас, см. пункт 1.
По поводу третьего — среди бесполезного функционала в CMS’ках встречается и полезный, но он зачастую так глубоко закопан и так усугублён кривыми архитектурными решениями, что его часто всё равно никто не использует.
==== ЭТАЛОН УЖОСА ⌘⌘ %% ====
Несмотря на то, что интернеты кишат критикой данной коммерческой CMS, причём даже по сравнению с другими, ''бесплатными'' (открыто-свободными) CMS, она почему-то всё ещё популярна. Причина кроется, наверное, разве что в маркетинге, потому что нормальных программистов у них, по-видимому, нет. Регулярно происходят выступления на конференциях, на которых то расскажут, что очередная маркетинговая фишка — Web Application Firewall — родилась, когда поняли, что даже опытные программисты у них ''зачастую не экранируют параметры'' в SQL-запросах… то о том, что на задачу «завести битрикс в AWS» у них ушёл год… То ещё о чём-нибудь.
Но зато мы имеем отличный пример CMS’ки с ужасной архитектуройэталонной жести, более, чем полностью, состоящей из говнокода, можем бугагагировать и рассматривать антипаттерны реализации. Итак, избранные примеры ужосов:
Начать стоит с дикого для 21 века стиля кода (пещерный стиль). Многие компоненты написаны не то что не объектно-ориентированно, а даже не процедурно — так как в коде зачастую ''вообще отсутствуют процедуры'', а просто идёт длииииинная портянка где-нибудь на 2000 строк. О каком-то структурировании такого кода речи, конечно, идти не может. О, скажем, наследовании я вообще молчу — оно там реализуется только с помощью копипасты.
Конторой на флаг поднимается то, что в битриксе есть MVC. При чём тут MVC — вообще непонятно: M — модель бизнес-объектов, инкапсулирующая логику работы с оными — там полностью отсутствует. Весь «MVC» заключается в том, что код компонента разделили на два файла — компонент и шаблон. Причём несмотря на тривиальность этого разделения, среди битрикс-разработчиков находятся люди, которым оно не нравится; они изобретают (а то и находят на прострах просторах интернета) довольно популярный антипаттерн «супер компонент», то есть пустую обёртку для шаблона, и всю логику пишут прямо в шаблоне. Один такой «супер компонент», например, изобрёл некто Иван Левый. Ну да — реально левый, что с него взять.
Прикольно реализована страница ошибки 404 «страница не найдена» — если, не дай бог, она обрабатывается битриксом, там будет 300 запросов в базу, и если, не дай бог, на главной окажется размещена битая ссылка, на которую будут заходить многие пользователи — сайт уйдёт в «само-DOS» (само-отказ-в-обслуживании), ибо обработка 404 съест все ресурсы.
«Инфоблоки», то есть наличие некоего ядра, служащего для хранения всех нестандартных сущностей, почему-то считается большим плюсом данной CMS, но в реальности ядро реализовано очень слабо, а порождаемая им структура базы данных весьма неоптимальна. И тут причина не только в предполагаемой квалификации программистов битрикса, а в куда более глубокой архитектурной проблеме — ''универсальное ядро хранения всех сущностей, которое будет и удобно, и оптимально, создать очень сложно''.
Это были только избранные ужасы, а в реальности их куда больше. За критикой можно отправиться хотя бы [[rupedia:1С-Битрикс|в русскую Википедию]]. Кстати, никаких гарантий на работу битрикса конторка не даёт, и это чётко прописано в лицензионном соглашении.
Но что характерно — есть подозрение, что если сделать CMS с более-менее нормальной, а не тупой, архитектурой, существовать она не сможет, потому что люди, которые ей пользуются — а это зачастую очень слабые программисты — её просто не поймут, и интернет заполнится отзывами о том, что она, например, слишком сложна для понимания. Подозрение недоказанное, но оно есть.
==== Зато ''«мы стали более лучше одеваться!»''{{star}} ⌘⌘ ====
Зато Битрикс24! И магазин компонентов!
И самая крутая версия {{mag|~250000 рублей}} стоит!
{{gray|<nowiki>:-(</nowiki> печаль и уныние.}}
-----
{{star}} …''«Овощи там, рожь!» © '' © Света из Иваново
==== Битрикс — не единственный пример проблем ⌘⌘ ==== '''УЖАСНЫЙ''' пример. Но не единственный. <div style="float: right; font-size: 600%; color: red">☹</div>* Любые движки с EAV, например:** {{mag|Magento}}** {{blue|WordPress}}* {{gray|Да и прочие CMS не блещут}} …но они хотя бы Open Source. === Фреймворки === ==== Фреймворки (PHP) ⌘⌘ %% ==== ОК, CMS не берём.
[[File:Frameworks.png|300px|link=]]
Но 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}}{{star}} -----{{star}} {{gray|Keep It Simply Stupid.}} ==== Шаблоны проектирования ==== Фреймворк — это не только и не столько функционал. Фреймворк также более или менее жёстко привязывает разработку и проектирование к каким-либо шаблонам. Шаблоны эти обычно не взяты с неба, а достаточно распространены и признаны, но это не отменяет то, что какие-то из них более применимы для определённых задач, а какие-то — менее. В то же время разрабатывать с использованием фреймворка и игнорировать паттерны, в нём заложенные — обычно либо неудобно, либо вообще невозможно. Это-то и приводит к шуткам о «фабриках проблем» и «фабрикам фабрик фабрик инструментов». Слепое принятие паттернов может быть полезно разве что для обучения начинающих разработчиков — пусть лучше они научатся паттернам, чем написанию битриксоподобных портянок. Возможно, проблема не в самих фреймворках, а в чрезмерной технологизации (Over-Engineering’е) — имеется ввиду, когда создатель системы, вместо простой реализации нужного функционала в соответствии с принципом KISS (Keep It Simply Stupid), сразу начинает чрезмерно его обобщать и закладывать ненужные точки расширения, результатом чего типично являются:* Лишние слои абстракции, в лучшем случае — просто лишние, а в худшем — ограничивающие и делающие неоптимальным использование нижележащих API.* Отсутствие точек расширения в нужных местах и наличие в ненужных.* Вынесение в конфигурацию ВСЕГО, чрезмерное обобщение и как итог — сложные (доменно-специфичные) языки конфигурации и описания функционала. Мем «введение в конфиги всем.ру, том 2» — когда я работал в Агаве над vsem.ru, конфиги там занимали около 470 килобайт и 12000 строк. ==== Фреймворки и SAPI ⌘⌘ %% ==== [[File:OtherWebNoAPI.svg|90px|left]][[File:PHP-SAPI.svg|120px|right]] <small>Серверов много, API тоже<br />{{gray|(модуль/CGI/SCGI/FastCGI/…)}}</small> <small>{{mag|Нет стандарта? ⇒ рождается обёртка}}<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|⇒}} Для библиотек не подходит: {{mag|⇒}} Доп. источник багов и дыр: {{mag|⇒}} Проблемы глобальных обновлений: {{mag|⇒}} «Автобусный фактор» ==== Область применения фреймворков ⌘⌘ ==== * Проект простой? {{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’ы по крайней мере не натворят совсем паршивых дел. В то же время — если ваши разработчики сильны, «ограничивать их фантазию» может означать «ограничивать их потенциал», а это уже не очень хорошо. Ну и, конечно, разглядывание деталей реализации фреймворка и критическая оценка тех самых заложенных в него практик идёт на пользу всем (лишним-то не будет узнать ещё одну технологию). ==== Закрытые, внутренние, малопопулярные фреймворки ⌘⌘ ==== Имеют дополнительные минусы:* {{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|Природа любит разнообразие.}}
* Главный плюс рукотворный: PHP-фреймворки — это мода, упрощающая продажу менеджерам, которые слышали buzzword, но не разбирались в вопросе.