-> Фреймворки же хороши не только для сложных, а вообще практически для любых проектов.
Фреймворки хороши для сайта из 5 страниц? Главная, Новости, Контакты? Я когда-то писал такие сайты на фреймворке, чувствовал себя крутым кодером от знания слов «Контроллер», «Модель», «Вьювер», а потом каждый раз ловил себя на мысли — что сэкономил бы себе массу времени, если бы был чуть попроще. А своя админка для каждого сайта — так ли это круто?
Да и кто у вас закажет сайт на фреймворке-то? С ним кроме компании-разработчика мало кто разберется.
И, поверьте, я видел много кода, который написан на фреймворке. Сам фреймворк тоже никогда не даст результата, если прогер не понимает базовых вещей и банально не умеет им пользоваться.
Видел, когда в методе контроллера вывод шел через switch case с обработкой урла, видел прямые запросы к базе во вьюхе. Редко, кто умеет и использует все возможности ORM. И т.д. В общем, проблемы те же самые, что и в Битриксе. Разницы никакой. Вот представьте себе Битрикс — как проект на каком-либо фреймворке (или попробуйте написать, если время и желание есть). Получите тот же говнокод, с гарантией.
-> Перфекционист в первую очередь обратится к гуглу.
Не всегда. С убеждением, что на этом «г-не» ничего хорошего все равно не напишешь — он может начать фигачить запросы куда попало. Тут не прямая связь, но она есть. Я потом немного общался с этим разработчиком… И он тоже (сюрприз!) не любит битрикс :)
И по минусам немного пройдусь:
— прожорливость («спец настройски», «спец хостинг», «включите кеширование»)
Плата за функциональность и методы оптимизации.
— изначально фуфловая архитектура, которую надо «принять» и писать в том же фуфловом стиле
А вот и пример, о котором я говорил выше )) Писать в том же фуфловом стиле вас никто не заставляет. Пишите грамотно. Возможности для этого есть.
— низкое качество самого кода (хотя есть люди которые минусом это не считают)
Да — есть такие люди :)
— цена. за такой продукт стыдно брать деньги
Есть люди, которым не стыдно брать деньги и не стыдно их отдавать.
— сообщество разработчиков
Первый раз слышу, чтобы сообщество разработчиков относили к минусу системы. Ну а стереотипы о том, что сообщество разрабочтиков этих — люди далекие или недалекие — это вообще ни в какие ворота. Прямое хамство и пустословие. Везде есть начинающие, есть середнячки, и есть гуру. И если гуру умеет создавать на Битриксе качественные сайты — то он все равно будет выше кодера, научившегося выводить hello world с помощью фреймворка. Сотый раз — дело не в инструменте. Дело в умении им пользоваться.
— маркетинг. все «неразработчики» свято верят в силу битрикса и если право выбора за ними то непременно выберут его.
Не все. Далеко. Многие студии, особенно начинающего уровня — отдают предпочтение вордпрессу, джумле и другим бесплатным CMS, потому что у них просто нет больших заказов.
2. Для того, чтобы изменить поведения метода — у нас всего один параметр (номер счета). По логике метода видно, что этого мало. То есть он закрыт для расширения. Для изменения поведения нам приходится только переписывать метод.
Вывод: код неидеален, система (в данном случае Symfony) тоже плохая. Что-то доработать на ней — невозможно. Я открыл код, посмотрел и понял, что за это ненавидят php-шников… Дайте яду! :)
Я уверен, что запросы к базе писал перфекционист, которому было противно разбираться с архитектурой битрикса, потому что он «открыл код и посмотрел, и понял, что никогда больше с этим работать не будет, потому что это убого»
Сами запросы написаны достаточно сложные. Хлебные крошки вывести из базы — это не мелочь по карманам )) Рекурсия есть, чувствуется, что человек что-то умеет. Не умеет только одного — работать с той системой, которую его попросили доработать.
К слову, хлебные крошки в битриксе выводятся одной строкой — подключением компонента. Об этом написано в документации. Гугл за доли секунды приводит нас к ссылке.
На счет сравнения битрикса с фреймворками типа симфони и yii… Ну, я понимаю, это сложно для понимания, когда Вы открыли код битрикса и посмотрели… Но это не то, с чем нужно сравнивать битрикс. Это разные сегменты рынка. Вообще разные. Фреймворки составляются для того, чтобы создавать сложные веб-приложения, с хорошей архитектурой и почти неограниченным бюджетом (удельный вес таких проектов на рынке, особенно российском, очень мал)
Битрикс — для того, чтобы создавать на нем сайты, уровня сложности до средней. В разумные сроки и с разумным бюджетом. Этот сегмент рынка гораздо шире.
Я тоже сходу разобрался, что делает этот код (вообще, думал, что он Ваш), и сходу могу сказать, что он неидеальный. Нарушает ряд принципов. Почитайте на эту тему. То, что не использует глобальные переменные — это гуд, конечно, но есть другие ошибки.
Идеального кода не существует. Это фантастика. Вот о чем я хочу сказать.
И оценивать систему по качеству кода — это утопия. Оценивать нужно продукт.
И я ни в коем разе не говорю о том, что Битрикс для создания гибких и сложных проектов лучше, чем фреймворк. Но даже фреймворк не обеспечит той гибкости, которую даст чистый лист и знание php. Мы ведь не о гибкости ведем сейчас речь, и не о качестве кода? А о умении использовать конкретный инструмент, и понимании для каких задач он может пригодиться. Верно?
-> Битрикс хорош для типового проекта, который идет из коробки битрикса, а если что-то требуется не стандартное, подбирай другое решение или пиши нужный функционал с нуля.
Это слишком общая фраза. Если что-то «нестандартное». В каждом проекте нужно голову включать и думать, насколько то нестандартное отклоняется от стандартного. Битрикс можно здорово кастомизировать штатными средствами.
А так каждый немного нестандартный проект с нуля писать… Не скрою — есть в этом элемент романтики. Но здравого смысла — не так много.
-> Писали про какую-то революционную ORM, я залез, а там, как в 2010, CIBlockElement::GetList, воистину разивается продукт
Ох… Вы же понимаете, что для обратной совместимости заменять в системе название ключевого метода, отвечающего за большую часть функционала сайта — неразумно? ) Или Вы чисто из принципа хотели, чтобы его название менялось в каждой версии? Это Вы, наверное, и имеете в виду под словом «развитие»?
Смешно, ей-богу. Впрочем, это типичный коммент о Битриксе…
— Битрикс? Да, это же говно.
— Почему говно?
— Ну как почему. Вот я открыл и посмотрел код… Так в нем даже названия методов ни разу не изменились )))
-> Ах да, помню веселые времена, когда находил у них баги, высылал патчи, а они вливали их как-то очень с опозданием, да еще и хамили
Вы каждый баг-репорт начинали со слов «битриксоиды далеки от программирования»? )
Разработчиков никто не заставляет пересаживаться на Битрикс. Но если уже пересели, то почему бы его не изучить получше?
Да — есть сообщества. Я там тоже многого не понимаю. Это люди, которые свой выбор сделали, и им нравится писать под Битрикс. Такие люди существуют и они могут дать качественный продукт на неидеальной системе. Выбор каждого — брать с них пример или с кого-нибудь другого, или идти своей дорогой.
В статье, по сути, идет анализ основных фейлов и попытка изобразить, что те же фейлы легко случились бы и на любой другой системе. Система играет небольшую роль. Главная роль — подход к ней.
Она очень урезана по сравнению с php. Работал как-то у нас один дотнетчик — через месяц пересел за изучение php. .NET версия развивается в разы медленнее, и не поспевает за своим старшим братом.
Я сам немного разработчик ) И я тоже люблю красивый код. Просто в данный момент времени пришлось подумать — а не стоит ли чуть сделать шаг навстречу маркетологам? Вдруг, не такое уж и УГ они предлагают. При ближайшем рассмотрении оказалось, что с системой работать можно.
Вот только крайне редко я захожу в методы основных классов и смотрю их работу. Нечего там делать. Документации хватает с головой. Если в документации чего-то нет, то хватает просто название метода и входные параметры посмотреть и становится ясно, что он делает. Но это тоже редко бывает.
Для большой массы сайтов при грамотном подходе Битрикс можно использовать как станок. И это экономит время разработчика. Которое он вполне может потратить на изучение других возможностей, написание своего движка… Ведь если студия развивается, то рано или поздно появляется клиент с большим проектом. Который уже удобнее реализовать на чем-то другом.
Я писал о изучении инструментов, а не о том, что не существуют хорошие разработчики. Конечно, они есть. Слава богу, очень много таких знаю. В том числе, и среди «битрикс-хейтеров».
Для покупок товаров без регистрации тоже есть готовые решения в маркетплейсе ) Но с Вами соглашусь — что такие доработки надо оценивать отдельно всегда.
Приходится лезть в код иногда. Хотя опять же — часто можно обойтись и событиями. Для той же покупки товара без регистрации, если я правильно понимаю, можно использовать обработчик события OnBeforeOrderAdd, в котором дописать регистрацию. В код компонента при этом лезть вовсе необязательно. Это не такая сложная доработка, если чуть изучить возможности системы, а не сходу лезть в код.
То есть — ошибка та же, увы. Недостаточное знание возможностей системы.
-> Вообще-то код пишут чтобы его читали.
Увы, клиенту чаще всего не интересны внутренности его сайта. Ему нужно, чтобы он работал. Как это сделают — уже дело десятое. Я — не большой сторонник фреймворком, по одной простой причине — не люблю велосипеды.
Пусть я напишу хороший код, но разве это цель? Цель — сделать продукт. А вот так — раз за разом писать контроллеры для вывода новостей, пагинации, хлебных крошек… Где-то на третьем проекте все это надоест. Я уже не говорю про самописные админки, отъедающие бОльшую часть времени и не покрывающие обычно и 20% функционала готовой CMS. Того же Битрикса.
На счет кода. github.com/Sylius/SyliusWebBundle/blob/master/Controller/Frontend/AccountController.php
Взял первый попавшийся контроллер. Нет — достаточно грамотно написано и структурировано, но Вы уверены, что это идеал? И что человек, который будет дорабатывать за Вами этот проект, сходу выполнит доработку, например, по добавлению разных типов файлов для формирования счета-фактуры? (у Вас метод renderInvoiceAction за это отвечает). Вы на 100% уверены, что здесь не нарушены принципы SOLID? И не перегружаете ли Вы этот метод излишним функционалом, который можно было бы вынести за его пределы? По сути — для такой несложной доработки — придется переписывать целый метод. Начисто. Он ведь подходит только для формирования файлов pdf, больше ни на что не способен.
Здесь есть ошибки, пусть они не так заметны как в некоторых компонентах Битрикса. Но это тоже не идеал. И наверняка найдется человек, который скажет «за такой код расстреливают». 100% найдется.
-> а на битрикс написан вообще хоть один тест?
Функционал проверки сайта, думаю, можно отнести к тестам. Хотя модульного тестирования в битриксе, конечно, нет. Он не для этого. Это законченный продукт. Вы не сравнивайте готовый продукт (паяльник) с набором запчастей для собирания паяльников, микроскопов и телескопов. Это несравнимые вещи ведь. Если клиенту нужен не красный паяльник, который есть в стандартной поставке, а синий, то ему проще порекомендовать готовый продукт. Если ему микроскоп нужен, то есть смысл подумать в сторону набора запчастей. А возможно и есть уже готовые микроскопы (а ведь скорее всего есть).
А где говорится о том, что надо изучать одну cms и пихать ее везде? В общем, чистым фрилансом не занимался никогда. Если и приходится, то это касается поддержки уже готовых проектов. А тут вопрос выбора cms по понятным причинам не стоит.
Выбирали за меня обычно. И по довольно странным соображениям. По ходу и рождались и идеи, что раз мы так хорошо умеем продавать Битрикс, то давайте хотя бы научимся с ним работать.
Я не согласен с утверждением, что 90% случаев — простейшие сайты.
Какой сайт называть простейшим? Вот хабр, к примеру. Очень сложный и навороченный сайт, но костяк — это вывод постов, комментарии, разбивка по тегам. Это можно реализовать на Битриксе штатными средствами за короткий период :)
Уверен, что можно объяснить клиенту это. Что вот сначала мы пишем костяк, а потом уже рассмотрим Ваши пожелания на счет улучшений.
Пресловутые 90% клиентов все равно меняют свои требования по ходу проекта. Ясная картина у них перед глазами встает только, когда что-то уже работает, и что-то можно нажать, протестировать… И тут начинаются «хотелки».
Собственно, это уже вопрос продаж и проектирования. Но в статье этому уделяется основное внимание.
Да — в заголовке в общем написано, что система популярна не ввиду своей идеальности. А ввиду своей раскрученности. В статье речь идет о том, как научиться справляться с этим. И какие ошибки на самом деле происходят в проектах на Битриксе, и точно ли вина системы в этом есть?
Если заказчик сам инициативный и заинтересованный, то проект чаще всего получится неплохой. Заказчик сам половину работы сделает — по проектированию, по дизайну, по идеям.
Тут речь больше шла о типовых сайтах, когда клиенту предлагается типовой совершенно обычный магазин. Клиенту не нужны бизнес-идеи, ему нужен продающий сайт. Как именно он это будет делать — это уже пусть исполнитель решает.
И вот тут начинаются косяки. Когда исполнитель в лице менеджера не понимает с какого конца подойти.
-> Даже если у сервера узкий канал — можно включить gzip
Не совсем понятно, Вы же пишете «система не должна тормозить на любых хостингах» и тут же «если не работает — можно включить gzip». Так любой хостинг или любой хостинг с gzip? Это не тождественно, совсем.
Для быстрой работы Битрикса достаточно установить несколько модулей, и установить несколько директив. Ну, и написать хороший код, отталкиваясь от возможностей системы. Все. Простые условия и все будет работать.
Это как бы и входит в понятие «хорошо спроектированная система на Битриксе».
Фреймворки хороши для сайта из 5 страниц? Главная, Новости, Контакты? Я когда-то писал такие сайты на фреймворке, чувствовал себя крутым кодером от знания слов «Контроллер», «Модель», «Вьювер», а потом каждый раз ловил себя на мысли — что сэкономил бы себе массу времени, если бы был чуть попроще. А своя админка для каждого сайта — так ли это круто?
Да и кто у вас закажет сайт на фреймворке-то? С ним кроме компании-разработчика мало кто разберется.
И, поверьте, я видел много кода, который написан на фреймворке. Сам фреймворк тоже никогда не даст результата, если прогер не понимает базовых вещей и банально не умеет им пользоваться.
Видел, когда в методе контроллера вывод шел через switch case с обработкой урла, видел прямые запросы к базе во вьюхе. Редко, кто умеет и использует все возможности ORM. И т.д. В общем, проблемы те же самые, что и в Битриксе. Разницы никакой. Вот представьте себе Битрикс — как проект на каком-либо фреймворке (или попробуйте написать, если время и желание есть). Получите тот же говнокод, с гарантией.
-> Перфекционист в первую очередь обратится к гуглу.
Не всегда. С убеждением, что на этом «г-не» ничего хорошего все равно не напишешь — он может начать фигачить запросы куда попало. Тут не прямая связь, но она есть. Я потом немного общался с этим разработчиком… И он тоже (сюрприз!) не любит битрикс :)
И по минусам немного пройдусь:
— прожорливость («спец настройски», «спец хостинг», «включите кеширование»)
Плата за функциональность и методы оптимизации.
— изначально фуфловая архитектура, которую надо «принять» и писать в том же фуфловом стиле
А вот и пример, о котором я говорил выше )) Писать в том же фуфловом стиле вас никто не заставляет. Пишите грамотно. Возможности для этого есть.
— низкое качество самого кода (хотя есть люди которые минусом это не считают)
Да — есть такие люди :)
— цена. за такой продукт стыдно брать деньги
Есть люди, которым не стыдно брать деньги и не стыдно их отдавать.
— сообщество разработчиков
Первый раз слышу, чтобы сообщество разработчиков относили к минусу системы. Ну а стереотипы о том, что сообщество разрабочтиков этих — люди далекие или недалекие — это вообще ни в какие ворота. Прямое хамство и пустословие. Везде есть начинающие, есть середнячки, и есть гуру. И если гуру умеет создавать на Битриксе качественные сайты — то он все равно будет выше кодера, научившегося выводить hello world с помощью фреймворка. Сотый раз — дело не в инструменте. Дело в умении им пользоваться.
— маркетинг. все «неразработчики» свято верят в силу битрикса и если право выбора за ними то непременно выберут его.
Не все. Далеко. Многие студии, особенно начинающего уровня — отдают предпочтение вордпрессу, джумле и другим бесплатным CMS, потому что у них просто нет больших заказов.
1. На него возложено слишком больше одной обязанности (вывод счета по номеру в конкретном шаблоне в конкретном формате)
Не пойму, почему у Вас не вызвал удивления вот этот кусок:
$generator->setOptions(
array(
'footer-left' => '[title]',
'footer-right' => '[page]/[topage]',
'footer-line' => true,
'footer-font-name' => '«Helvetica Neue»,Helvetica,Arial,sans-serif',
'footer-font-size' => 10,
)
);
а вызвал удивление этот
$this->content .= '';
Это ведь небольшое лицемерие с Вашей стороны? )
2. Для того, чтобы изменить поведения метода — у нас всего один параметр (номер счета). По логике метода видно, что этого мало. То есть он закрыт для расширения. Для изменения поведения нам приходится только переписывать метод.
Вывод: код неидеален, система (в данном случае Symfony) тоже плохая. Что-то доработать на ней — невозможно. Я открыл код, посмотрел и понял, что за это ненавидят php-шников… Дайте яду! :)
Сами запросы написаны достаточно сложные. Хлебные крошки вывести из базы — это не мелочь по карманам )) Рекурсия есть, чувствуется, что человек что-то умеет. Не умеет только одного — работать с той системой, которую его попросили доработать.
К слову, хлебные крошки в битриксе выводятся одной строкой — подключением компонента. Об этом написано в документации. Гугл за доли секунды приводит нас к ссылке.
На счет сравнения битрикса с фреймворками типа симфони и yii… Ну, я понимаю, это сложно для понимания, когда Вы открыли код битрикса и посмотрели… Но это не то, с чем нужно сравнивать битрикс. Это разные сегменты рынка. Вообще разные. Фреймворки составляются для того, чтобы создавать сложные веб-приложения, с хорошей архитектурой и почти неограниченным бюджетом (удельный вес таких проектов на рынке, особенно российском, очень мал)
Битрикс — для того, чтобы создавать на нем сайты, уровня сложности до средней. В разумные сроки и с разумным бюджетом. Этот сегмент рынка гораздо шире.
Идеального кода не существует. Это фантастика. Вот о чем я хочу сказать.
И оценивать систему по качеству кода — это утопия. Оценивать нужно продукт.
И я ни в коем разе не говорю о том, что Битрикс для создания гибких и сложных проектов лучше, чем фреймворк. Но даже фреймворк не обеспечит той гибкости, которую даст чистый лист и знание php. Мы ведь не о гибкости ведем сейчас речь, и не о качестве кода? А о умении использовать конкретный инструмент, и понимании для каких задач он может пригодиться. Верно?
Это слишком общая фраза. Если что-то «нестандартное». В каждом проекте нужно голову включать и думать, насколько то нестандартное отклоняется от стандартного. Битрикс можно здорово кастомизировать штатными средствами.
А так каждый немного нестандартный проект с нуля писать… Не скрою — есть в этом элемент романтики. Но здравого смысла — не так много.
Ох… Вы же понимаете, что для обратной совместимости заменять в системе название ключевого метода, отвечающего за большую часть функционала сайта — неразумно? ) Или Вы чисто из принципа хотели, чтобы его название менялось в каждой версии? Это Вы, наверное, и имеете в виду под словом «развитие»?
Смешно, ей-богу. Впрочем, это типичный коммент о Битриксе…
— Битрикс? Да, это же говно.
— Почему говно?
— Ну как почему. Вот я открыл и посмотрел код… Так в нем даже названия методов ни разу не изменились )))
Вы каждый баг-репорт начинали со слов «битриксоиды далеки от программирования»? )
Да — есть сообщества. Я там тоже многого не понимаю. Это люди, которые свой выбор сделали, и им нравится писать под Битрикс. Такие люди существуют и они могут дать качественный продукт на неидеальной системе. Выбор каждого — брать с них пример или с кого-нибудь другого, или идти своей дорогой.
В статье, по сути, идет анализ основных фейлов и попытка изобразить, что те же фейлы легко случились бы и на любой другой системе. Система играет небольшую роль. Главная роль — подход к ней.
Вот только крайне редко я захожу в методы основных классов и смотрю их работу. Нечего там делать. Документации хватает с головой. Если в документации чего-то нет, то хватает просто название метода и входные параметры посмотреть и становится ясно, что он делает. Но это тоже редко бывает.
Для большой массы сайтов при грамотном подходе Битрикс можно использовать как станок. И это экономит время разработчика. Которое он вполне может потратить на изучение других возможностей, написание своего движка… Ведь если студия развивается, то рано или поздно появляется клиент с большим проектом. Который уже удобнее реализовать на чем-то другом.
Я писал о изучении инструментов, а не о том, что не существуют хорошие разработчики. Конечно, они есть. Слава богу, очень много таких знаю. В том числе, и среди «битрикс-хейтеров».
Приходится лезть в код иногда. Хотя опять же — часто можно обойтись и событиями. Для той же покупки товара без регистрации, если я правильно понимаю, можно использовать обработчик события OnBeforeOrderAdd, в котором дописать регистрацию. В код компонента при этом лезть вовсе необязательно. Это не такая сложная доработка, если чуть изучить возможности системы, а не сходу лезть в код.
То есть — ошибка та же, увы. Недостаточное знание возможностей системы.
Увы, клиенту чаще всего не интересны внутренности его сайта. Ему нужно, чтобы он работал. Как это сделают — уже дело десятое. Я — не большой сторонник фреймворком, по одной простой причине — не люблю велосипеды.
Пусть я напишу хороший код, но разве это цель? Цель — сделать продукт. А вот так — раз за разом писать контроллеры для вывода новостей, пагинации, хлебных крошек… Где-то на третьем проекте все это надоест. Я уже не говорю про самописные админки, отъедающие бОльшую часть времени и не покрывающие обычно и 20% функционала готовой CMS. Того же Битрикса.
На счет кода. github.com/Sylius/SyliusWebBundle/blob/master/Controller/Frontend/AccountController.php
Взял первый попавшийся контроллер. Нет — достаточно грамотно написано и структурировано, но Вы уверены, что это идеал? И что человек, который будет дорабатывать за Вами этот проект, сходу выполнит доработку, например, по добавлению разных типов файлов для формирования счета-фактуры? (у Вас метод renderInvoiceAction за это отвечает). Вы на 100% уверены, что здесь не нарушены принципы SOLID? И не перегружаете ли Вы этот метод излишним функционалом, который можно было бы вынести за его пределы? По сути — для такой несложной доработки — придется переписывать целый метод. Начисто. Он ведь подходит только для формирования файлов pdf, больше ни на что не способен.
Здесь есть ошибки, пусть они не так заметны как в некоторых компонентах Битрикса. Но это тоже не идеал. И наверняка найдется человек, который скажет «за такой код расстреливают». 100% найдется.
-> а на битрикс написан вообще хоть один тест?
Функционал проверки сайта, думаю, можно отнести к тестам. Хотя модульного тестирования в битриксе, конечно, нет. Он не для этого. Это законченный продукт. Вы не сравнивайте готовый продукт (паяльник) с набором запчастей для собирания паяльников, микроскопов и телескопов. Это несравнимые вещи ведь. Если клиенту нужен не красный паяльник, который есть в стандартной поставке, а синий, то ему проще порекомендовать готовый продукт. Если ему микроскоп нужен, то есть смысл подумать в сторону набора запчастей. А возможно и есть уже готовые микроскопы (а ведь скорее всего есть).
Выбирали за меня обычно. И по довольно странным соображениям. По ходу и рождались и идеи, что раз мы так хорошо умеем продавать Битрикс, то давайте хотя бы научимся с ним работать.
Какой сайт называть простейшим? Вот хабр, к примеру. Очень сложный и навороченный сайт, но костяк — это вывод постов, комментарии, разбивка по тегам. Это можно реализовать на Битриксе штатными средствами за короткий период :)
Уверен, что можно объяснить клиенту это. Что вот сначала мы пишем костяк, а потом уже рассмотрим Ваши пожелания на счет улучшений.
Пресловутые 90% клиентов все равно меняют свои требования по ходу проекта. Ясная картина у них перед глазами встает только, когда что-то уже работает, и что-то можно нажать, протестировать… И тут начинаются «хотелки».
Собственно, это уже вопрос продаж и проектирования. Но в статье этому уделяется основное внимание.
Тут речь больше шла о типовых сайтах, когда клиенту предлагается типовой совершенно обычный магазин. Клиенту не нужны бизнес-идеи, ему нужен продающий сайт. Как именно он это будет делать — это уже пусть исполнитель решает.
И вот тут начинаются косяки. Когда исполнитель в лице менеджера не понимает с какого конца подойти.
Хотя вообще, идеальный код — это чистый лист.
Не совсем понятно, Вы же пишете «система не должна тормозить на любых хостингах» и тут же «если не работает — можно включить gzip». Так любой хостинг или любой хостинг с gzip? Это не тождественно, совсем.
Для быстрой работы Битрикса достаточно установить несколько модулей, и установить несколько директив. Ну, и написать хороший код, отталкиваясь от возможностей системы. Все. Простые условия и все будет работать.
Это как бы и входит в понятие «хорошо спроектированная система на Битриксе».