вступ
Доброго вам дня!
Так уже склалося, що в моїй практиці я часто працюю на різні студії / компанії з розробки сайтів та інших digital послуг. Відповідно у кожної компанії, яка підходить серйозно до етапу виробництва, існують норми і вимоги щодо розробки для всіх рівнів (дизайн, верстка та інтеграція + програмування), свій або запозичений у кого-то Coding Style і стандартні фреймворки і бібліотеки (jQuery, modernizer, etc.).
Після закінчення, якого то часу я став помічати, що фахівці приділяють набагато більше уваги вимогам по розробці, ніж самій розробці та креативу. Дизайнери стали зазивати з уточненнями «чи можна так зробити?», Верстальники забули про переносяться інтерфейс і багаторазове використання елементів, так що вже говорити, вони забули про банальні класи-властивості допомагають у швидкій розмітці, не кажучи вже про CSS фреймворки, які в концепцію більшості вимог (моїх і сторонніх) просто не вписувалися. Повільно, але вірно я починав розуміти, що це веде до замкнутого циклу, такою собі рекурсії, а введення нових технологій в сформувалися вимоги сприймалося так болісно, що ми «відкладали їх до великого замовника».
Помилки робочої області
Отже. Навіщо ж нам потрібна робоча область і що таке шапка і підвал сторінки. У більшості шаблонних сайтів все як завжди і як описано вище. Давайте візьмемо до уваги сайти більш творчі, де дизайнер не зашитий в рамки CMS, де верстальник використовує свій улюблений CSS фреймворк і ми отримаємо сайт, кожна сторінка якого є твором мистецтва і практично не схожа на попередню. Візьмемо один стовпчик головну сторінку і розіб'ємо її на три колонки в інформаційних сторінках і на дві в функціональних (каталог наприклад). Що ми побачимо всередині? Що ми побачимо в шаблонах? У кращому випадку це один шаблон з милицями по дірректорію або ще гірше використання буфферізаціі, в гіршому це три шаблони для різної структури, що повторюють одні й ті ж елементи в шапці і підвалі. Прошу не робіть так більше! Ваша робоча область це те, що відрізняється на всіх сторінках сайту. Якщо у вас на одній сторінці є сайдбар а на інший ні, не потрібно городити милиці! Це абсолютно не підтримуваний код. Зробіть робочу область, яка включає в себе і сайдбар і основний контент. Ставте div.some_class для кожної сторінки! Знаєте чого ви боїтеся при такому підході? Як же будуть жити контент-менеджери, якщо ми контентную область для статичних сторінок не розмітимо. Я теж цього боявся. Таке трепетне ставлення призводить до способів і методів розробки, які складно назвати інакше як убогими. Я закликаю Вас не бояться і шукати витончені рішення, а не ті яким навчають на онлайн курсах по Бітрікс. Тим більше що платформа дозволяє.
Страх зворотної сумісності
Страх викликаний можливим відмовою компонента, і як наслідок втратою лояльності замовника змушує йти на такі вчинки, які публікувати соромно, але ж ті, хто це зробив, пишаються собою! Вибачте, але навіть криво написана логіка в result_modifier.php теж злітає, але ж використовується коробковий компонент. Ви ж розробники, творці, програмісти, чарівники, врешті-решт! Але немає, у страху очі великі і тому всі ми йдемо на поводу рамок і обмежень. Боже, а як же живуть розробники, які використовують рішення з маркетплейс. Давайте підемо ще далі. Як живуть студії, які продають сайти на фреймворками і безкоштовних CMS, частина з яких не сьогодні так завтра взагалі зникне з ринку? Ви скажете - «вони прийдуть до нас, і ми будемо переносити сайт на Бітрікс!» Серйозно? Сайти, які обмежені тільки фантазією творця і підкорили свою нішу ринку ніколи не перейдуть на інший продукт. Мені навіть страшно уявити як же Google або Yandex живі без Бітрікс. Єретики, все єретики! Ви ще тут? Тоді продовжимо.
Навіщо нам потрібен Бітрікс?
Бітрікс це конструктор з купою готових модулів в адмінку (яких у більшості немає). Одні Інфоблоки, на яких можна побудувати будь-яку логіку, говорять самі за себе, мовляв «у нас немає модуля" новини "," каталог "або" слайдер ", зате є система, на якій можна їх побудувати». Навіщо потрібен такий низькорівневий конструктор? Для двох речей цілком зійде:
- Створення галузевих сайтів на основі готових або пропонованих рішень
- Створення своєї внутрішньої логіки поведінки веб-додатки
Page Controller + Front Controller
Це дуже цікава тема. Так Бітрікс працює через page controller. Що означає - підключати нам ядро системи в кожній публічній файлі, кожній сторінці на сайті відповідає свій файл на сервері - стара і заїжджена платівка, воно і зрозуміло ми ж назад сумісні, але тільки в тому випадку якщо ми продовжуємо сидіти в рамках системи. Цікаво те, що в системі є так само і Front Controller, але він реалізований в межах комплексних компонентів, і тут у збочених розробників, які стежать не тільки за оновленнями Бітрікс а й за ринком в цілому (я маю на увазі всякі MVC фреймворки) з'являються ідеї - якомога назавжди забути про більшість проблем старої архітектури вельми витонченим способами. Тут як раз мова про написання комплексного компонента, який буде підключений на головну сторінку сайту. Бітрікс сам буде обробляти маршрутизацію, а ви маєте право вибудувати свою логічний ланцюжок більше підходящу для проектування конкретного завдання. Та й зберігання статичних сторінок у вигляді елементів Інфоблоки - скоріше благо, ніж єресь, яке допомагає ще більше відійти від рамок «робочої області».
Продовження під катом.
надмірна кастомизация
Далі виявилося ще страшніше. Не знаю чим Поделкіни керувалися, але вони розробили свій власний імпорт з 1С (редакція Бізнес), і замість того щоб довести його до розуму змусили 1С програмістів переписати функціонал імпорту з ручним завантаженням кілька XML на сервер, а самим імпортом займався cron. Тобто такий собі самопісний XML імпорт, який теж є в коробці, але їм знехтували.
Підводячи підсумки, хочу ще раз акцентувати увагу на кількох важливих речах:
Сподіваюся, я зміг хоч трохи донести те, що складалося у мене в голові протягом багатьох років. А якщо це не так я буду чекати багать і факелів. Дякую всім, завіса, ура!