13 494
правки
Изменения
м
Истина же в том, что легче всего расширять Истинное удобство расширения: {{mag|KISS, YAGNI}}{{star}}
→Дополнительные мысли
Конторой на флаг поднимается то, что в битриксе есть MVC. При чём тут MVC — вообще непонятно: M — модель бизнес-объектов, инкапсулирующая логику работы с оными — там полностью отсутствует. Весь «MVC» заключается в том, что код компонента разделили на два файла — компонент и шаблон. Причём несмотря на тривиальность этого разделения, среди битрикс-разработчиков находятся люди, которым оно не нравится; они изобретают (а то и находят на просторах интернета) довольно популярный антипаттерн «супер компонент», то есть пустую обёртку для шаблона, и всю логику пишут прямо в шаблоне. Один такой «супер компонент», например, изобрёл некто Иван Левый. Ну да — реально левый, что с него взять.
Прикольно реализована страница ошибки 404 «страница не найдена» — если, не дай бог, она обрабатывается битриксом, там будет 300 запросов в базу, и если, не дай бог, на главной окажется размещена битая ссылка, на которую будут заходить многие пользователи — сайт уйдёт в «само-DOS» (само-отказ-в-обслуживании), ибо обработка 404 съест все ресурсы. Да и в целом, ~50 запросов на генерацию несложной страницы с включённым кэшем и 500—600 с выключенным — норма для вполне оптимизированного битрикс-сайта. Посему работа данной CMS на разделяемом хостинге обычно обречена на провал.
«Инфоблоки», то есть наличие некоего ядра, служащего для хранения всех нестандартных сущностей, почему-то считается большим плюсом данной CMS, но в реальности ядро реализовано очень слабо, а порождаемая им структура базы данных весьма неоптимальна. И тут причина не только в предполагаемой квалификации программистов битрикса, а в куда более глубокой архитектурной проблеме — ''универсальное ядро хранения всех сущностей, которое будет и удобно, и оптимально, создать очень сложно''.
Это были только избранные ужасы, а в реальности их куда больше. За критикой можно отправиться хотя бы [[rupedia:1С-Битрикс|в русскую Википедию]]. Кстати, там же упоминается, что никаких гарантий на работу битрикса конторка не даёт, и это чётко прописано в лицензионном соглашении.Также можно читать различные обсуждения на различных хабрах, вроде такого: http://habrahabr.ru/post/152173/
Но что характерно — есть подозрение, что если сделать CMS с более-менее нормальной, а не тупой, архитектурой, существовать она не сможет, потому что люди, которые ей пользуются — а это зачастую очень слабые программисты — её просто не поймут, и интернет заполнится отзывами о том, что она, например, слишком сложна для понимания. Подозрение недоказанное, но оно есть.
…но они хотя бы Open Source.
==== Проблемными являются почти все CMS ====
Битрикс, конечно, пример вполне себе ужасный, и ужасный главным образом из-за успешного маркетинга. Не будь маркетинга, он бы существовал на уровне слабоизвестного поделия и не резал бы глаза. Но благодаря маркетингу и политике «партнёрства», увы, он проник в кучу проектов, и создаёт множество проблем.
Всю ту же ругань можно адресовать и к прочим general-purpose CMS, к тем же WordPress, Joomla, специфичным Magento и osCommerce — с их смесью вёрстки и кода и EAV-хранилищем, которому грустно живётся при условии сложной атрибутики и большой посещаемости… И использовать их в серьёзном проекте — это так же курам на смех.
Но у этих CMS есть одно большое оправдание: они '''БЕСПЛАТНЫ'''. Причём — не просто бесплатны, а '''СВОБОДНЫ'''. А битрикс — это закрытая, платная, недешёвая вещь в себе, имеющая, тем не менее, либо худшее, либо по меньшей мере сравнимое с ними качество.
=== Фреймворки ===
* {{red|☹}} Раннее внедрение излишней расширяемости
-----
{{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.
* Отсутствие точек расширения в нужных местах и наличие в ненужных.
Второй плюс работает, только если фреймворк «готовить» по всем канонам, не разламывая его вдребезги и следуя заложенным в него шаблонам разработки: фреймворк будет ограничивать фантазию разработчиков. Хорошо это или плохо? Ну, в случае, если ваши разработчики — неокрепшие начинающие умы, тогда, наверное, хорошо: может быть, принятые во фреймворке практики неидеальны, но зато ваши junior’ы по крайней мере не натворят совсем паршивых дел. В то же время — если ваши разработчики сильны, «ограничивать их фантазию» может означать «ограничивать их потенциал», а это уже не очень хорошо.
Ну и, конечно, плюс в обучении — обучении — ясно, что разглядывание деталей реализации фреймворка и критическая оценка тех самых заложенных в него практик идёт на пользу всем. Никому не будет лишним узнать ещё одну технологию, а в общемировом плане — плане — пусть лучше начинающие программисты изучают фреймворки, чем CMS — CMS — в отличие от CMS, код фреймворков обычно вменяем, да и о «паттернах» и прочей лабуде начинающие узнают быстрее.
==== Закрытые, внутренние, малопопулярные фреймворки ⌘⌘ ====
* Общность — ЛЕНЬ, вечное желание получить результат, ничего не делая.
* 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 предназначен для организации небольшой «баннерной сети», а, например, не для показа 5 баннеров на сайте.
* Главный плюс рукотворный: PHP-фреймворки — это мода, упрощающая продажу менеджерам, которые слышали buzzword, но не разбирались в вопросе.
