3,2
рейтинг
22 июля 2013 в 12:02

Разработка → ZendFramework + Bitrix из песочницы

Пожалуй, это был один из самых муторных челленжей для меня за последнее время.

Итак. Мы занимаемся технически сложными проектами, потенциально рассчитанными на высокие нагрузки (highload). Так получилось, что среди систем управления контентом пока победил Битрикс. Его хотят клиенты. Судя по нашему опыту — highload на Битриксе — очень даже реальная задача, если делать все аккуратно.



Обычно в проектах, где много форм, личных кабинетов или какая-то сложная логика — мы предлагали на выбор клиенту реализацию на Zend Framewok или на Битрикс. Минус ZendFramework был в том, что на нем нужно писать админку. Минус Битрикса — он плохо приспособлен под проекты со сложной бизнес-логикой: там толком нет MVC и местами отвратительный код и API. Маркетинговые байки-балалайки про ядро D7, которым уже 2 года — мы в расчёт не берем:

«Talk is cheap. Show me the code» (Linus)

Итак, возникла идея на сложных проектах использовать ZendFramework с управлением данными из админки Битрикса. Мы реализовали архитектуру таким образом, что можно как использовать ViewHelper внутри шаблонов Bitrix, так и вызывать компоненты внутри View. За все типовые вещи сайтов (каталоги товаров, текстовые страницы, новости и прочее) отвечает Bitrix. За сложные формы, личные кабинеты, профили — Zend. В итоге мы получили быструю и чрезвычайно гибкую систему, с приятным в работе кодом, потратив примерно 3 дня на интеграцию.

Внедрения:


1. Пилотный проект. Мы решили делать Scrumban на ZendFramework, поскольку хотели иметь структурированный код, который бы радовал. Именно на этом проекте мы имели время на эксперименты и смогли отработать основные моменты интеграции:
  • Совместные сессии.
  • Совместное соединение с базой (ха-ха, старый код Битрикса не умеет работать с MySQLi, а использует устаревший драйвер MySQL. ZendFramework это старье не поддерживает, поэтому пришлось немного попрограммировать).
  • Обвязку к инфоблокам для работы с моделями.
  • Роутинг.

2. Преодолеть скепсис самых скептических. Поскольку у нас на руках был уже рабочий прототип связки — мы могли обсуждать код. Я встретил яростное сопротивление одного чувака моей компании. В течение примерно часа он придирался к нашей реализации, что в итоге помогло нам найти несколько ошибок и сделать ряд улучшений. После этого у критикана не осталось логических аргументов и мы могли двигаться дальше.

3. Эксперименты с производительностью. Мы реально боялись, что загрузка каркаса ZendFramework будет стоить значительного времени системы. После ряда оптимизаций мы аккуратно вынесли загрузку в autoload. Разница между стартом чистого битрикса и нашей связки составила 0,033 сек, а это — копейки по сравнению с возможностью быстро разрабатывать хорошо структурированный код.

4. Экспериментальные коммерческие проекты. Их было два. Нам удалось довольно четко понять, в какой момент надо бить по рукам за попытку переписать стандартную логику работы Битрикса на ZF.

5. Общее собрание с рассказом чо-каво. У нас такое проводится регулярно и называется HolyWarModeOn. Собрались-обсудили. Я плохо подготовился, поэтому поймал (кроме заинтересованности) еще пачку скепсиса. Но у меня уже было несколько рабочих систем на руках, код которых меня радовал. Как и их производительность. Поэтому я был уверен: все получится.

6. Root Cause Analysis. Меня попросили четко обосновать — с какой целью нужна интеграция с ZF. Я потратил примерно полдня на анализ корневых причин и сделал распечатку в полстены с деревом причинных связей. Распечатка провисела пару недель на всеобщем обозрении: отличный пример баннерной слепоты.

Самое основное, что мне хотелось получить:
  • Структуризация и стандартизация кода на сложных проектах. MVC. ORM.
  • Необходимость поднятия мотивации разработчиков, вынужденных ковырять копрокод битрикса.
  • Ускорение разработки за счет совместных наработок (например, у нас есть отличный логгер изменений базы данных, который позволяет смотреть, как менялась база с прошлого релиза).

7. Подготовка чистой сборки битрикса. Мы используем одну чистую сборку с активированной NFR-лицензией, в которую интегрированы наши наработки. В принципе, у всех разработчиков есть потенциальная возможность что-то туда закоммитить. При создании нового проекта специальный скрипт создает новый репозиторий и базу данных на dev-сервере. В новый репозиторий разворачивается копия чистой сборки (триалочка).

8. Обучение ZF. Не секрет, что знание ZF требует большего мастерства, чем клепание сайтиков чисто на Битриксе. Мы провели несколько холиваров, где детально разобрали архитектуру MVC и внедрили в обиход основную терминологию. После этого каждый из разработчиков получил тестовую задачу и время на ее решение. Нужно было на практике пощупать контроллеры, формы, хэлперы, валидаторы. По-моему, это было драйвово ;) К тому времени уже 80% разработчиков поучаствовали в коммерческих проектах на ZF.

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

10. Регулярные практики code review. Это довольно сложная практика. Требует усидчивости и вдумчивости. Чтобы найти что-то посерьезней, чем откровенный говнокод или лишние пробелы — нужно работать головой. Иногда имеет смысл проводить code review в паре с разработчиком. Особенно если архитектура системы нетривиальна. Я считаю code review важной практикой обучения. Разбор реального кода проектов дает разработчику обратную связь. А всем нам важно понимать, правильно мы развиваемся или нет.

Мне кажется, мы нашли неплохой баланс между тем, чтобы:
  • не демотивировать разработчиков необходимостью копаться в быдлокоде битрикса.
  • делать качественную архитектуру.
  • не изобретать велосипедов, по максимуму используя возможности CMS и каркаса MVC.
  • поставлять заказчику высокотехнологичные продукты с четким, ясным и поддерживаемым кодом.

Больше оптимизма, друзья.
Владимир Завертайлов @zevvssibirix
карма
108,0
рейтинг 3,2
Главный бармалей
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (9)

  • +3
    Звучит хорошо, но не проще ли было написать типовую админку на MVC Zend, чем совмещать слона и ежа?
    • 0
      Клиент просит Битрикс. Сильный маркетинг ;). Ну и если по честноку — интернет-коммерция у них самая сильная из отечесвенных и многих зарубежных аналогов (магента нервно курит :)
      • +1
        Можно по подробней! Основные достоинства.
        • 0
          Очень холиварный аспект, думаю что из этого сравнения нужно делать отдельный пост ;) Штатная интеграция с Большой Желтой Программой например (да, я прекрасно знаю, что можно найти бесплатное или купить платное для магенты, но стоимость будет сопоставима с Битриксом; да, я прекрасно знаю ограничения штатной интеграции ;) Но для многих клиентов возможность принципиальна при выборе cms.
      • 0
        А вот тут промелькнула интрига. Можно подробностей?
  • 0
    Тезис, что «делать сложный CRUD нескольких связанных сущностей с веб-формами на битриксе — это ад» мы давно приняли и смирились.
    Но до вашего уровня хардкора не дошли. Браво!
    А D7 чувствую будем ждать еще годик…
  • 0
    Был недавно проект, в котором скрестили NetCat и Symfony2. Причины те же — клиент хотел NetCat, а схема данных весьма сложная. Кроме того, пригодился twig, т.к. нужен был кастомизируемый шаблон с кучей параметров для клепания дочерних сайтов менеджерами из админки. В целом, проект живет и здравствует.
  • 0
    Если не секрет, что за цифры на графике? 180k посетителей — это за день или за час, минуту?
  • 0
    Пост про то, что менеджеры прогнулись под клиента.
    Работаю и с ZF/ZF2 и с Битриксом, и если честно, то в шоке. Вопрос один — «зачем?»
    Клиент пашет поля, но ему нравится порше, говорят, что порше очень хорош. Мы прикрутили к порше плуг.
    В итоге ни пахать не сможет, ни ездить комфортно.

    Если клиент хочет битрикс, а вы любите писать на ZF, то вы ищите другого клиента, а клиент — другого исполнителя.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.