Вступление
Доброго времени суток!
Так уж сложилось, что в моей практике я часто работаю на разные студии/компании по разработке сайтов и прочих digital услуг. Соответственно у каждой компании, которая подходит серьезно к этапу производства, существуют нормы и требования по разработке для всех уровней (дизайн, верстка и интеграция + программирование), свой или позаимствованный у кого-то Coding Style и стандартные фреймворки и библиотеки (jQuery, modernizer, etc.).
Когда то я тоже составлял многостраничные требования для HTML, CSS и JS, чтобы, как мне казалось, облегчить задачу программистам и себе в частности по интеграции этой самой верстки в систему. Тогда мне казалось, что все правильно — дизайнер помогает верстальщику с подготовкой макета, верстальщик помогает программисту с подготовкой качественной верстки, готовой к интеграции, а программист, сняв с себя часть работы, концентрируется на том, чтобы клиенту и контент-менеджеру все было понятно и просто. Такой тандем действительно приносил свои плоды и я пошел дальше, расставляя требования для дизайнеров, в их числе и шаблонная система и соблюдение, так называемой, «рабочей области» на всех страницах, не смотря на их содержание. Как же я тогда был не прав.
По истечении, какого то времени я стал замечать, что специалисты уделяют на много больше внимания требованиям по разработке, чем самой разработке и креативу. Дизайнеры стали зазывать с уточнениями «можно ли так сделать?», верстальщики забыли про переносимые интерфейс и многократное использование элементов, да что уж говорить, они забыли про банальные классы-свойства помогающие в быстрой разметке, не говоря уже про CSS фреймворки, которые в концепцию большинства требований (моих и сторонних) просто не вписывались. Медленно, но верно я начинал понимать, что это ведет к замкнутому циклу, этакой рекурсии, а введение новых технологий в сформировавшиеся требования воспринималось так болезненно, что мы «откладывали их до крупного заказчика».
Ошибки рабочей области
Все мы прекрасно знаем, что рабочая область это то место, куда встраивается индексный файл (читай Представление конкретного запроса или действия). В большинстве фреймворков это реализовано через вывод переменной $content или через метод объекта showContent(), в Битрикс это «макрос» который просто при сохранении разделяет файлы на шапку и подвал. Конечно, при такой системе логично ставить рабочую область сразу после всех сквозных элементов (в их числе заголовок страницы и хлебные крошки) а сквозные элементы, если они меняют свое представление, подключать через включаемые области с визуальным редактором и управлять этими, так называемыми виджетами, через рекурсивное подключение в секцию. И действительно, почему бы нет. Первым и самым важным требованием в таком случае будет обязательный вынос заголовка страницы за рабочую область (в своей практике я столкнулся с программистом, который это требование выносил во главу угла и очень много и громко ругался касательно косорукости людей которые так не делают, употребляя при этом такие слова как «качественный продукт», «простота реализации» и так далее). Я согласен, что этот подход имеет место жить, но только для шаблонных и тиражных сайтов! Запомните, вы навсегда застрянете в однотипности решений, которые выпускаете, если будете в каждом проекте выводить заголовок страницы через ShowTitle() и я объясню почему. Наверное, в пределах данной статьи я еще не раз буду разжигать огонь недоверия, и ломать множество сложившихся стандартов, насылая на себя гневные отзывы и толпы хомячков-инквизиторов в комментариях, но это стоит того.
Итак. Зачем же нам нужна рабочая область и что такое шапка и подвал страницы. В большинстве шаблонных сайтов все как всегда и как описано выше. Давайте возьмем во внимание сайты более творческие, где дизайнер не зашит в рамки CMS, где верстальщик использует свой любимый CSS фреймворк и мы получим сайт, каждая страница которого является произведением искусства и практически не похожа на предыдущую. Возьмем одноколоночную главную страницу и разобьем ее на три колонки в информационных страницах и на две в функциональных (каталог например). Что мы увидим внутри? Что мы увидим в шаблонах? В лучшем случае это один шаблон с костылями по дирректориям или еще хуже использование буфферизации, в худшем это три шаблона для разной структуры, повторяющие одни и те же элементы в шапке и подвале. Прошу не делайте так больше! Ваша рабочая область это то, что отличается на всех страницах сайта. Если у вас на одной странице есть сайдбар а на другой нет, не нужно городить костыли! Это абсолютно не поддерживаемый код. Сделайте рабочую область, которая включает в себя и сайдбар и основной контент. Ставьте div.some_class для каждой страницы! Знаете чего вы боитесь при таком подходе? Как же будут жить контент-менеджеры, если мы контентную область для статических страниц не разметим. Я тоже этого боялся. Такое трепетное отношение приводит к способам и методам разработки, которые сложно назвать иначе как убогими. Я призываю Вас не боятся и искать изящные решения, а не те которым учат на онлайн курсах по Битрикс. Тем более что платформа позволяет.
Я понимаю, что после написанного каждый второй, скорее всего, будет ждать от меня решения, что вот я взмахну волшебной палочкой, вытащу заветного кролика из своей шляпы, и всем все станет понятно. Пожалуй, я намекну, но не более, так как эта тема другой статьи. Когда только появился HTML5 со своей семантикой у меня пришла в голову мысль, а как же я так одну контентную область оберну и в section и в article в зависимости от содержимого страницы, не смотря на то что, как оказалось, оборачивать все надо в main или не оборачивать вообще, я нашел решение. Мне даже интересно, а многие ли из вас, мои дорогие читатели, пользовались шаблонами страниц или ваши включаемые области так и подключают шаблон «Другой»? Фишка в том, что любой код, находящийся внутри первых и последних php дескрипторов (в которых у стандартной страницы расположено подключение шапки и подвала, а так же всякие $APPLICATION-SetTitle()) в большинстве случаев прозрачен для визуального редактора, что означает — контент менеджер не видит ничего, что находится внутри. Таким образом, я создал шаблон который изначально включал в себя section.content и, вы не поверите, ShowTitle(), для статических страниц, а в динамике использовал другой шаблон в котором я мог оперировать различными семантическими тегами по своему собственному желанию.
Страх обратной совместимости
Перед очередным обзором повторюсь, я, когда то тоже считал это правильным.
Мы все любим и не любим Битрикс ровно по одной и той же причине, то есть этот пункт можно записать и в плюсы и в минусы. Они действительно боятся потери обратной совместимости, но должны ли боятся мы? Я расскажу что, как и почему.
Из-за страха потери обратной совместимости, а как следствие потери доходов от покупки продления платформы клиентом, мы сейчас довольствуемся достаточно сильно устаревшей архитектурой, ни тебе singleton ни нормального ООП и всячески ждем выхода D7 в свет в надежде на что то более приятное. Более того этот страх навязан большинству разработчиков, которые говорят «ни в коем случае не используйте свои компоненты, максимально используйте компоненты из коробки, лучше перепишите их логику в result_modifier.php». Я не призываю ломать ядро системы, ни в коем случае. Получать обновления это благо и использование компонентов из коробки тоже, но пардон не в тех случаях, когда вы пишите новый компонент в вышеупомянутом файле вроде как, оставив возможность системе этот компонент обновлять. Я как-то встретил кастомизацию в которой $arResult был просто удален и собран заново. А некоторые студии требовали многостраничных обоснований причины использования своих компонентов. Ребят, одумайтесь, даже в Битрикс при создании тиражных решений, например интернет-магазина, кастомизируют свои компоненты, создавая новые с префиксом shop.* или что то другое в зависимости от решения. Этих компонентов больше нигде нет, более того они не установятся если вы выберете чистую установку той же самой бизнес редакции.
Страх вызванный возможным отказом компонента, и как следствие потерей лояльности заказчика заставляет идти на такие поступки, которые публиковать стыдно, а ведь те, кто это сделал, гордятся собой! Простите, но даже криво написанная логика в result_modifier.php тоже слетает, а ведь используется коробочный компонент. Вы же разработчики, создатели, программисты, волшебники, в конце концов! Но нет, у страха глаза велики и поэтому все мы идем на поводу рамок и ограничений. Боже, а как же живут разработчики, которые используют решения из маркетплейс. Давайте пойдем еще дальше. Как живут студии, которые продают сайты на фреймворках и бесплатных CMS, часть из которых не сегодня так завтра вообще пропадет с рынка? Вы скажете — «они придут к нам, и мы будем переносить сайт на Битрикс!» Серьезно? Сайты, которые ограничены только фантазией создателя и покорившие свою нишу рынка никогда не перейдут на другой продукт. Мне даже страшно представить как же Google или Yandex живы без битрикса. Еретики, все еретики! Вы еще здесь? Тогда продолжим.
Зачем нам нужен Битрикс?
Кто то скажет что это лучшая CMS на рынке, кто то будет доказывать с пеной у рта, что Битрикс решает множество задач и благодаря этой системе можно сделать почти что угодно, кто то будет приводить пример удобной админки и многое другое. Хочу разрушить все мифы разом. Битрикс это отраслевая CMS. Даже в самом Битрикс это поняли. Сколько обновлений подряд они вводят функционал для интернет-магазинов? Мобильное приложение для магазина, CRM для магазина в виде отдельного продукта, SKU для сложных магазинов, свой собственный шаблонный и крутой магазин, требования для разработчиков типовых магазинов в маркетплейс, топ-10 проданных решений в маркетплейс — интернет-магазины, интеграция с PayPal до выхода PayPal на рынок, интеграция с 1С из коробки. Иными словами магазины, магазины, магазины. Так же советую не упускать из виду медицинские и образовательные решения. Битрикс, это уже давно продукт для клиента, а не для разработчика. Задача Битрикса продать себя в том виде, в котором он есть, и дать максимум функционала для лидирующих отраслей, а партнеры и разработчики нужны для дизайна и проектирования больше чем для разработки в целом. Как давно мы видели обновление SEO-модуля или работу с Wiki, а так же форумом и соц.сетями? Это не прибыльно сейчас. Прибыльно лидировать там, где лежат деньги. Они даже бизнес редакции разделили на базовую и расширенную чтобы продавать «Бизнес» чаще «Малого бизнеса».
Битрикс это конструктор с кучей готовых модулей в админку (которых у большинства нет). Одни инфоблоки, на которых можно построить любую логику, говорят сами за себя, мол «у нас нет модуля „новости“, „каталог“ или „слайдер“, зато есть система, на которой можно их построить». Зачем нужен такой низкоуровневый конструктор? Для двух вещей вполне сойдет:
- Создание отраслевых сайтов на основе готовых или предлагаемых решений
- Создание своей внутренней логики поведения веб-приложения
Page Controller + Front Controller
Это очень интересная тема. Да Битрикс работает через page controller. Что означает — подключать нам ядро системы в каждом публичном файле, каждой странице на сайте соответствует свой файл на сервере — старая и заезженная пластинка, оно и понятно мы же обратно совместимы, но только в том случае если мы продолжаем сидеть в рамках системы. Интересно то, что в системе есть так же и Front Controller, но он реализован в пределах комплексных компонентов, и тут у извращенных разработчиков, которые следят не только за обновлениями битрикса но и за рынком в целом (я имею ввиду всякие MVC фреймворки) появляются идеи — как можно навсегда забыть о большинстве проблем старой архитектуры весьма изощренным способами. Тут как раз речь о написание комплексного компонента, который будет подключен на главную страницу сайта. Битрикс сам будет обрабатывать маршрутизацию, а вы вправе выстроить свою логическую цепочку больше подходящую для проектирования конкретной задачи. Да и хранение статических страниц в виде элементов инфоблока — скорее благо, чем ересь, которое помогает еще больше отойти от рамок «рабочей области».
Продолжение под катом.
Чрезмерная кастомизация
Наверное, у многих сложилось впечатление, что я тут все твержу «кастомизируйте все и вся», однако это не так. Существует и обратная сторона медали. Не буду сильно углубляться, просто приведу пример.
Как то на днях мне попался проект от крупной столичной и очень известной студии, назовем ее «Поделкины» дабы не снимать масок. Так же я знал, что над этим проектом работал и другой программист-фрилансер после сдачи проекта Поделкиными. И о боже, что я увидел. Во-первых — сломанное ядро с целью (внимание!) сделать вывод каталога через свои классы в режиме ООП. Во-вторых — логика и представление в одном месте. Более того был создан компонент под названием «пустой компонент». Внутри которого прямо в шаблоне была перемешана та самая логика с тем самым представлением, и все это было сделано внутри компонента Каталог для вывода разделов / элементов. Я был в шоке. Поддерживать и редактировать такой код невозможно в адекватном состоянии. Более того от фрилансера в коде часто встречались комментарии вроде «надо бы переверстать», «послушайте вот этот трек пока разбираетесь в коде», «кто разберется что тут делают эти функции, пожалуйста — комментируйте» и так далее.
Дальше оказалось еще страшнее. Не знаю чем Поделкины руководствовались, но они разработали свой собственный импорт из 1С (редакция Бизнес), и вместо того чтобы довести его до ума заставили 1С программистов переписать функционал импорта с ручной загрузкой несколько XML на сервер, а самим импортом занимался cron. То есть этакий самописный XML импорт, который тоже есть в коробке, но им пренебрегли.
Да Битрикс это конструктор, но не до такой же степени все менять, зачем вам нужен готовый продукт с функционалом из коробки и возможностью кастомизировать любой код, если вы все равно все сломаете и сделаете по-своему? Финалом для меня стало объявление константой в dbconn id инфоблоков для дальнейшей работы со своими классами.
Итого
Подводя итоги, хочу еще раз акцентировать внимание на нескольких важных вещах:
- Старайтесь отойти от стандартов разработки как можно дальше, оставляйте только необходимое.
- Не бойтесь создавать новые или кастомизировать существующие компоненты для решения не типовых задач.
- Используйте инструменты и модули из маркетплейс, пишите свои модули, тем самым дополняя функционал, но, не перезаписывая его, велосипеды не нужны.
- Используйте Битрикс по назначению — «Right tool for the right job». Не забывайте что CMS или Framework это лишь 20% в разработке сайта, если сайт можно сделать с помощью чистого php или микро-фреймворков — используйте их.
- Не перестарайтесь с катосмизацией и не ломайте ядро системы — это не поддерживаемое зло.
Надеюсь, я смог хоть немного донести то, что складывалось у меня в голове в течение многих лет. А если это не так я буду ждать костров и факелов. Всем спасибо, занавес, ура!
Автор: xskif
Спасибо за статью, очень позновательно