Вообще говоря, «имею опыт работы» — очень даже аргумент, особенно когда организуешь не свой личный проект, а промышленного монстра. Если нужно наладить стройный релизный цикл, мало прочитать даже эту замечательную книжку. Опыт работы очень помогает, когда появляются исследования истории, откаты, переносы задач по одной в релизную ветку и все вот это релизное. Я уж не упоминаю о задачах спасения перетертых или поврежденных данных.
Так что автор все правильно сделал: для большого проекта — знакомая СКВ, для себя — Гит.
Это вопрос, о котором спорят годами ) Лично я всегда придерживался мнения, что PHP — сам отличный шаблонизатор.
При решении специфических задач, конечно, можно прикрутить дополнительный. К примеру, если есть команда верстальщиков, которые уже знают Twig, но вообще никак не знают PHP. Или если хочется использовать БЭМ на сервере, можно использовать BH для PHP.
На самом деле, это действительно хороший аргумент ЗА. Но, мне кажется, те, кто хочет развернуть без сильного разработчика платформу, которая без написания кода интегрируется с 1С должен четко понимать, что ему не надо хотеть выходить за возможности стандартных компонентов и визуального конфигурирования. Битрикс — категорически не для написания кода.
Все равно же это лишняя трудность. Ее можно оправдать тем, что несложно с ней справиться, но я придерживаюсь мнения, что никогда не нужно оправдывать неудачные решения.
Опять же, Битрикс поддерживает модель наивной разработки на PHP — когда каждый файл является страницей. Это плохо как с точки зрения разработки, так и с точки зрения безопасности.
Проблема хранения контента отдельных страниц в СКВ в диффе между продакшеном и репозиторием. Не коммитить же контент-менеджеру каждый раз при изменении текста.
Изменение настроек инфоблоков скриптом — это выход, но мне кажется, что уж очень это замороченный способ. Особенно с учетом подстановки ID инфоблоков прямо в код, где добавляются компоненты (кстати, он потом коммитится, как соотносится с dev-копией?)
Я не в курсе, честно говоря, как в текущих версиях, но во времена, когда я работал с этой CMS идеология хранения контента в ней была не лучшей: редактирование статических страниц подразумевало непосредственное изменение php-файлов на жестком диске, админка инфоблоков была приспособлена только для новостей и каталогов.
Опять же, не очень понятно, как на Битриксе строить процесс деплоя: контент хранится прямо в файлах — о контроле версий можно не мечтать; структура данных описывается настройками инфоблоков — она является непереносимой.
Мы разрабатывали админку точно под необходимую бизнес-логику. Сначала использовали фреймворк Kohana, потом перешли на Yii.
В итоге получили полное отделение данных от кода, структура данных описывалась миграциями и классами моделей, которые отлично версионировались. Деплоймент заключался в обновлении версии кода и запуске миграций.
Дополнительным плюсом этих решений является инфраструктура для юнит- и интеграционных тестов. Битрикс же является просто нетестируемым. Я даже не уверен, что его ядро покрыто тестами.
Я полностью поддерживаю идею с отказом от реализации нестандартной функциональности через стандартные компоненты, абсолютно очевидно, что попытка такой реализации приводит к разведению болота в коде.
Вопрос в том, зачем вообще использовать в таком проекте Битрикс?
Это-то яснее ясного, но какая мотивация у исполнителей, которые, явно имея способности в деле программирования, выбирают такую специализацию? Мне кажется, сейчас в IT не такая бедственная ситуация, чтобы хвататься за любое дело, лишь бы приносило какой-то доход. Да и не самое это прибыльное из любых.
Когда-то, когда я зеленым новичком начинал свою карьеру в маленькой веб-студии, я помимо воли получил опыт по созданию сайтов на Битриксе: по «натягиванию шаблонов», интеграции с 1С, созданию типового сайта, на котором первая партия доработок выливалась в трагедию в трех актах. Поэтому, когда я продолжал карьеру в другой веб-студии, где у меня уже было право голоса, у нас установилось правило всеми силами отговаривать клиента от Битрикса, а при невозможности этого заламывать нереальную цену. По правде говоря, было страшновато, что кто-нибудь согласится-таки, и я рад, что те времена позади, и Битрикс угрожает мне разве что в кошмарных снах.
Позже, уже имея опыт во всех этих паттернах и прочих эджайлах, я вернулся к коду Битрикса… Я сочувствую людям, которым приходится с этим работать, разбираться в документации и хранить в голове знания по «API» этой платформы. И никак не могу я понять, героизм ими движет или мазохизм.
В одном внушающем доверие источнике, а именно в Симпсонах, показывали пушку для стрельбы футболками. Я думаю, можно переоборудовать ее и для стрельбы ватниками.
Так что автор все правильно сделал: для большого проекта — знакомая СКВ, для себя — Гит.
При решении специфических задач, конечно, можно прикрутить дополнительный. К примеру, если есть команда верстальщиков, которые уже знают Twig, но вообще никак не знают PHP. Или если хочется использовать БЭМ на сервере, можно использовать BH для PHP.
Опять же, Битрикс поддерживает модель наивной разработки на PHP — когда каждый файл является страницей. Это плохо как с точки зрения разработки, так и с точки зрения безопасности.
<?=— не short_open_tag. Она доступна всегда.Изменение настроек инфоблоков скриптом — это выход, но мне кажется, что уж очень это замороченный способ. Особенно с учетом подстановки ID инфоблоков прямо в код, где добавляются компоненты (кстати, он потом коммитится, как соотносится с dev-копией?)
Опять же, не очень понятно, как на Битриксе строить процесс деплоя: контент хранится прямо в файлах — о контроле версий можно не мечтать; структура данных описывается настройками инфоблоков — она является непереносимой.
Мы разрабатывали админку точно под необходимую бизнес-логику. Сначала использовали фреймворк Kohana, потом перешли на Yii.
В итоге получили полное отделение данных от кода, структура данных описывалась миграциями и классами моделей, которые отлично версионировались. Деплоймент заключался в обновлении версии кода и запуске миграций.
Дополнительным плюсом этих решений является инфраструктура для юнит- и интеграционных тестов. Битрикс же является просто нетестируемым. Я даже не уверен, что его ядро покрыто тестами.
Вопрос в том, зачем вообще использовать в таком проекте Битрикс?
Позже, уже имея опыт во всех этих паттернах и прочих эджайлах, я вернулся к коду Битрикса… Я сочувствую людям, которым приходится с этим работать, разбираться в документации и хранить в голове знания по «API» этой платформы. И никак не могу я понять, героизм ими движет или мазохизм.