Полный цикл жизни проекта: html,css,js > php, шаблоны, изменения, переиспользование?

Question

[xanuho]

В создании сайтов, удобно использовать и поддерживать имеющиеся наработки, шаблоны, библиотеки, блоки.
Какие подходы, вы используете для переиспользования кода и контроля над всеми стеками в процессе жизни проекта?

Например: создаём вёрстку (допустим используя bootstrap или свои ходовые блоки на jade, плюс стили, плюс javascript), получаем голый фронтенд, дальше "натягиваем" на CMS, следовательно образуется разрыв между генерируемыми шаблонами (например всё собирается посредством Gulp, подключение форм, прописанные role, скрипты и прочее).
Если в будущем, потребуется изменить что-нибудь в проекте, внешний вид, стили. Просто пересобрать из исходников фронтенда не получится, а значит нужно ручками править, проект обрастает правками, тяжело поддерживать, теряется гибкость/модульность, и т.д.

В идеале мне видятся универсальные темплейты: например чтобы добавить в проект карусель, есть папка с файлами, php, js, css, которую мы подключаем быстро и легко внося небольшие нужные изменения. При этом на выходе получаем собранный проект.

Симпатизирует в этом плане BEM, но достаточно сложно с наскока работать в полную силу, чтобы и BEM и PHP.
Пробовал реализовать используя системы сборки, но затык образуется после натяжки (близко не пощупал ещё jadePHP).

В общем, решил посоветоваться, кто как работает? На своём опыте, встречал лишь древний подход, генерим статику, потом натяжка, дальнейшая жизнь/правки под версионным контролем "на живую" скрестя пальцы.

Comments

[i]

Еще не ответ, но близко https://github.com/bem/bem-forum-content-ru/issues/175

[xanuho]

Илья Рогов: Понимаю, спасибо, упомянул вкратце в топике, достаточно сложновато там со всеми этими инструментами. Вот и интересно узнать, как у ребят проекты собираются в команде/на потоке или большие живут изменяются.

Answer 1

[Константин Китманов]

Подход давно выработан: пакетные менеджеры. Для фронтенда это npm/bower (или, может быть, component, но это уже чуть более широкая вещь), которым можно подсовывать адрес приватного git/hg репозитария. Только добавьте в .git_ignore node_modules и bower_components.

Другой вариант -- git submodule, но это будет более геморройно.

Comments

[i]

совсем не в тему

[Константин Китманов]

Илья Рогов: с чего бы это?

[i]

Константин Китманов: хорошо скажу иначе, твой ответ о использовании пакетных менеджеров не раскрывает цикла верстка -> внедрение

[Константин Китманов]

Илья Рогов: мы с тобой на брудершафт не пили. Окей, почему нет? Потому что верстак не умеет коммитить в гит?) Ну так в болото его такого, криворукого.

[xanuho]

Константин Китманов: Ну причём тут bower вообще? Причём тут знание git? О каком пакете/ах вы говорите? Раскройте тему, может мы чего не знаем?

[Константин Китманов]

xanuho: честно, не понимаю, в чем проблема.

[xanuho]

Константин Китманов: Не зачем тогда и писать ответы на уровне "читайте книги". Я задал понятный вопрос, вы ответили слишком абстрактно чтобы другие смогли им воспользоваться. Приведите хоть примеры какие-нибудь по теме вопроса, ссылки там, или имена пакетов, принцип подхода.

[Константин Китманов]

xanuho: вопрос был: как реюзать код. Ответ: воспользоваться пакетными менеджерами. Я честно не понимаю, в чем проблема. На пальцах:

Написали мы прекрасный слайдер, простестили.
Теперь выдираем его из проекта и кладем в отдельный репозитарий -- скрипты, стили, etc.
Подключаем его в проект через bower: bower install mySlider=mygit.example.com/myslider...., в системе сборки правим соответствующие пути к файлам.
Теперь делаем другой проект, слайдер выглядит и ведет себя по-другому. Тут есть несколько вариантов: предусмотреть в слайдере темизацию, сделать несколько гитовых веток (bower умеет ставить с точностью до ветки, до тэга или до коммита), или тупо оверрайдить стили. В случае с ветками переносить багфиксы между ними можно с помощью git cherry-pick.

[xanuho]

Константин Китманов: Спасибо за вариант. Пучок веток для темизации..

Answer 2

[Алексей Ярошевич]

Текущий подход достаточно заморочен, если знаешь все прелести БЭМ.

Сейчас мы делаем:
0. Дизайнер нарисовал макет
1. Верстаем руками html: a.html
2. пишем руками стили: a.css
3. пишем руками js: a.js
4. Это все передаем бекендеру и он:
5. Доверстывает хтмл и разбивает на шаблоны, из a.html получает A.tmpl, B.tmpl, C.tmpl, ...
6. Дописывает стили в своих файлах, а часто еще и разбивает их на части: A.scss, B.scss, ...
7. Дописывает js, и тоже часто разбивает: A.js, B.js, C.js
8. Какой-то бэкенд собирает из кусков шаблонов страницу, и часто создает css, js только из нужных кусков

А дальше: Пришел новый макет. И что делать?

И БЭМ в данном случае решает проблему, поскольку у него есть стек технологий, позволяющий верстальщику работать сразу с шаблонами и разобранными js/css(less/sass/stylus) файлами.

На практике получается так:
0. Макет.
1. Верстальщик смотрит на макет, и разбивает его на куски (компоненты) сразу;
2. Пишет bemjson (или jsx) вместо html;
3. Создает шаблоны, стили и js для каждого из блоков;
4. Передает это все бэкенд программисту (обычно через гит, потому что так удобнее);
5. Бэкендер без изменений использует эти файлы для генерации страницы, и просто генерирует описанный верстальщиком bemjson (или jsx).

И, О МАГИЯ, они могут работать над проектом параллельно, даже если придет новый макет.

C php действительно есть нюансы, которые сложно разглядеть, просто потому, что нет большого кол-ва пользователей и стек не устоялся.
Мы у себя используем велосипед, который собирает все сам, и почти готовы перейти на enb используя bh-php.
Большая проблема, как оказалось, использование декларативных шаблонизаторов — верстальщики не сразу въезжают что и как. Но когда въехали — я не знаю тех, кто возвращается на императивные (типа мусташей, джейдов, smarty, etc.).

Можно начать с https://github.com/bem/project-stub/tree/php-bem-bh и позадавать вопросы на форуме https://ru.bem.info/forum/ — люди поделятся своими историями.