В этой статье речь не пойдёт о новомодных ES6-фреймворках и headless-drupal. Речь пойдёт о банальной вёрстке. И не спешите закрывать страницу, если вы гордо именуетесь бэкенд девелопером, т.к. часть из рассматриваемых вопросов частично касается и бэкенда, ведь банальный альтеринг формы для добавления нужных классов и обёрток лежит как раз в зоне ответственности бэкенда. А тому, кто сам и верстает, и кодит, тем более должно быть интересно.

Сразу оговорюсь, что имеется в виду разработка коммерческих сайтов с уникальным дизайном, т.е. по макетам, нарисованным профессиональным дизайнером, не лишённым навыков и чувства вкуса. Под словом "эффективность" понимается простота и скорость самого процесса разработки. Изложенная ниже информация почерпнута не из умных книжек, а из жизненного опыта. Итак, начнём.
1. Выучи уже наконец-то CSS!
Звучит глуповато? Но не настолько глупо, как вопросы разработчиков с почти 10-летним стажем о том, как увеличить кнопку при наведении. Нормальные люди в помощью CSS рисуют попугаев и даже создают игры, а ты даже не знаешь, как приделать треугольничек к всплывающей подсказке, не вводя новых html-элементов. Изучи каскады, специфичность, анимации через transition и keyframes, гадиенты там всякие, особенности разных position, псевдоклассы, псевдоэлементы. И не мучай людей дурацкими вопросами - всё давно написано в гугле.

2. Используй препроцессоры.
SASS или LESS - это по вкусу, но ни в коем случае не копайся в богомерзком CSS! Недавно слышал мнение одного признанного специалиста, что ему препроцессоры не нужны, т.к. в его проектах обычно поверх базовой темы порядка 200 строк оверрайда CSS. Ну если ты делаешь сайты для гиков вроде себя или меня, то бутстрап с другим логотипом вполне сойдёт, а нормальным людям такое не интересно, поэтому и денег тебе за такое никто не даст. В любом коммерческом сайте будет от 3000-5000 строк CSS и выше, потому используй препроцессоры, чтобы не копипастить куски длинных селекторов и не насиловать скролл в поисках нужного цвета. Что касается сборщика (компилятора), сейчас в моде gulp. Хотя можно использовать и что-нибудь другое, более того, при должном умении тебя не будет смущать, что проект до тебя скомпилировали чем-то другим, если он попал к тебе на доработку, можешь перекопилировать тем, чем тебе удобно, главное, предварительно изучить старый конфиг, чтобы не упустить ничего, например автопрефиксер. А некоторые вообще компилят LESS и SASS саблаймом или PHPStorm-ом, что, должно быть удобно, но не так гибко настраиваемо.

3. Используй CSS-фреймворки.
Благо их полно на любой вкус. Никто не сомневается в твоих способностях задавать ширину колонкам, но фреймворки принято использовать лишь потому, что многие вещи там сделаны до тебя. Вопреки распространённому мнению, CSS-фреймворки не делают сайты похожими друг на друга. Любой вменяемый дизайн можно сделать одинаково хорошо на любом фреймворке, либо без него, внешне различий не будет, но будут различия в затраченном времени. Не забываем предыдущий пункт, поэтому должно быть ясно, что под CSS-фреймворком понимается его SASS или LESS-версия. Раньше я использовал Zen-grids, сейчас использую Bootstrap. Бутстрап, конечно, будет помощнее. Бутстрап - это не только сетка и менюшка-гамбургер. Там полно совершенно потрясающих вещей, таких, как bootstrap-modal, с помощью которого достаточно обернуть блок в нужный класс и сделать ссылку с нужным классом, по клику на которую блок будет всплывать в модульном окне, а по умолчанию он будет скрыт. Весьма удобно для небольших форм, например обратного звонка. А буквально на днях я узнал, что там есть даже карусель Пусть и сильно простая, но иногда сойдёт. В общем, не поленись изучить документацию по используемому фреймворку и жить станет легче.
4. Наследуйся от базовых тем.
Под любой распространённый фреймворк есть базовая тема drupal. Благодаря использованию базовой темы, ты получишь уже сконфигурированный фреймворк, останется только навести красоту. Более того, я рекомендую использовать те темы, которые поддерживают создание субтем через drush, ибо взрослому дяде не подобает руками копаться в файлах, копируя и переименовывая их. Именно поэтому я использую не bootstrap, а Radix. Есть там правда один маленький косяк, я писал об этом здесь, но пока не пофиксили, т.к. надо будет немного переписать drush-команду. Обязательно изучи документацию по используемой теме, в первую очередь почитай, как там надо запускать Gulp. Некоторых смущает, что в базовых темах и генерируемых субтемах "много хлама". На самом деле это не так. Там отражён правильный и стандартизованный подход к темизации, а если ты привык всё валить в один файл - переучивайся.

5. Всегда начинай вёрстку с переопределения variables.
Есть в любой нормальной теме файл _variables.scss или _variables.less. В этом файле описаны все базовые переменные - брейкпоинты, цвета, размеры и типы шрифтов и т.д. Этот файл нужно обязательно изучить вдоль и поперёк и переопределить всё под текущий проект, ибо не зная этого, можно написать десятки строк кода, переопределяя, к примеру, цвет и размер инпутов вместо того, чтобы задать значения двум-трём переменным.

6. Сделай нормальную легенду цветов.
Легенда цветов должна быть по схеме "название цвета: код цвета; назначение цвета: название цвета". Почему? Расмотрим пример:

Вроде бы всё круто. Если нам понадобится сменить оттенок серого, то мы можем сделать это в одном месте. А что будет, если нам для кнопок и инпутов вдруг понадобится два разных оттенка? Придётся лезть в код и выискивать, где мы применяли переменную $gray и менять её на другую. Но ведь можно сделать проще:

Теперь мы можем просто присвоить новое значение для $button_color и не париться с поиском его упоминаний. Может быть на двух цветах это выглядит неочевидно, но когда у нас в реальном проекте с десяток цветов и несколько десятков групп элементов, то это очень полезно.

7. Используй классы фреймворка в шаблонах.

Это очень удобно, когда ты просто переопределил шаблон, а у тебя уже всё стоит на своих местах. Не забывай, что классы можно назначать и из админки, например в панеляхи представлениях, но порой этого недостаточно и бывает проще создать пару новых шаблонов, чем потом мучаться определять всё в стилях. Кстати, для любителей панелей и bootstrap есть замечательный модуль Radix Layouts, который содержит порядка 30 лэйаутов для панелей, оптимизированных под bootstrap. Модуль совместим с любыми темами, использующими bootstrap.

Помимо указанных способов, добавлять классы и обёртки можно в hook_form_alter, используя префиксы и суффиксы или задавая атрибуты элементов формы. Также можно использовать функции препроцессинга. Всё это не всегда кажется простым, но если у вас уже есть свёрстанный html-макет, то всё, перечисленное в этом пункте, вам очень понадобится.

Кстати, во многих фреймворках есть миксины, имитирующие поведение стандартных классов, поэтому вовсе не обязательно писать на каждую мелочь шаблоны или препроцессы и уж тем более не обязательно вручную задавать все ширины и отступы, когда можно просто написать что-то вроде "include make-sm-column(3)" и элемент будет вести себя так же, как если бы у него был класс ".col-sm-3".

8. Структурируй код
Не вали весь свой код в один файл. Подключай импортом к одному файл много своих less или sass-файлов и компилируй их в один css. В большинстве распространённых тем в субтеме уже есть множество заготовок в виде пустых файлов.
Если надо, создавай свои файлы, главное, чтобы стили в них были объединены тематически. Зачем так делать? Есть три причины:
1. Звук скролла твоей мышки раздражает окружающих.
2. От обильного пользования скроллом может развиться туннельный синдром
3. Преждевременно вышедшие из строя мышки загрязняют окружающую среду.
Если этих причин недостаточно, то поверь на слово, что навигация по коду становится намного более быстрой, порой можно даже не смотреть номер строки в фаербаге, ведь и так понятно, в каком файле текст, а в его 200 строках всё как на ладони.

9. Грамотно используй медиа-запросы
Когда-то было модно писать медиа-запросы в отдельном файле или все вместе в конце файла. Это неудобно, т.к. стили одного и того же элемента оказываются разбросаны в разных местах. Лучше сразу писать медиазапрос для элемента в конце блока его стилей.

Например, как в примере выше. Тут мы использовали миксин breakpoint - довольно удобная штука, подобное есть во многих фреймворках, поэтому не лишним будет изучить, как пользоваться этим миксином. Как правило, breakpoint задаёт min-width, следовательно, правила по умолчанию пишутся под самый маленький экран и с увеличением экрана могут переопределяться. Однако по ситуации можно писать и более сложные запросы, например, с указанием максимальной и минимальной ширины одновременно. И конечно же, не забудь про media print {} ! В 21 веке только идиоты пишут какой-то отдельный функционал для версий для печати, а у нормальных людей под печать просто отдельные правила CSS.

10. Используй миксины
Любой фрагмент кода, состоящий из более, чем трёх строк, встречающийся в коде более двух раз, уже достоин того, чтобы стать миксином. Заверни в миксины всякие часто встречающиеся в проекте градиенты, тени и т.д.

11. Не используй монструозные модули для слайдеров

Взять к примеру тот же Slick - чтобы повесить его на вьюху, надо скачать библиотеку Slick, установить его модуль, а также отдельный модуль для вьюс и ещё чёрти что. И это для того, чтобы получить интерфейс с десятками настроек, которые надо настраивать отдельно под каждый слайдер на сайте. А потом ещё будешь, как дурак, переопределять его стандартные стили. Зачем? Можно же проще - берём slick.min.js, подключаем его к своей теме, а в скрипте темы инициализируем slick всего парой строчек js. При этом html-разметку вообще не надо переопределять.

Вангую вонь в комментах по поводу того, что нет смысла подключать скрипт, который, возможно, нужен не на всех страницах. Могу сразу ответить на это: slick.min.js месит 41 килобайт и при включенной агрегации js пусть лучше он загрузится на первой странице, закэшируется в браузере и не будет создавать при загрузке других страниц лишник http-запросов.

12. Удаляй из шаблонов лишние обёртки
Ни для кого не секрет, что html-код, выдаваемый друпалом по умолчанию избыточен и содержит множество обёрток. Нельзя сказать, что это большая проблема, но и хорошего в этом мало, ведь на некоторых страницах количество байт разметки может превышать количество информативного текста, а это всё паразитный трафик. Поэтому я при переопределении любых шаблонов всегда смотрю, какие из обёрток мне не нужны, ведь простую разметку и верстать легче. Но тут главное не переборщить - некоторые из обёрток могут быть критически важны для AJAX-запросов.

Ну вот, пока у меня всё. Надеюсь, мой стиль изложения не задел ничью тонкую душевную организацию

И традиционно в качестве пиара моего говнобложика ссылка на оригинал статьи: http://wellsolutions.by/article/effektivnaya-razrabotka-frontenda-na-drupal