воскресенье, 20 января 2013 г.

Про верстальщиков

Мы на работе часто срёмся между собой по техническим вопросам. Каждый думает, что он знает, как лучше, и пытается доказать оппоненту свою правоту. В основном, эти споры заканчиваются очень просто – либо мы оцениваем трудозатраты на реализацию какого-то решения, сравниваем их с получаемой в перспективе выгодой, и делаем выводы.

Если мы делаем какой-нибудь простенький сайтец, типа рекламного промо-сайта или простейшего каталога какой-нибудь фигни, который вряд ли будет обрастать функциональностью полноценной CRM-системы, то я рекомендую не строить монструозных систем, а быстро всё слепить из того, что есть. Если же проект сложный, ты мы выбираем решение, которое потом проще будет поддерживать (наращивать функциональность и чинить нарощенное) – скорее всего, все модели будем описывать вручную, наплодим классов, ну и так далее. Неправильно взятый курс на старте в итоге выльется в десятки, а то и сотни часов бесполезных трудозатрат.

Программисты обычно быстро понимают эти простые вещи и стараются им следовать, чтоб облегчить жизнь себе и коллегам. Но сегодня я бы хотел рассказать про верстальщиков. Очень многие представляют себе, что хороший верстальщик должен просто сверстать HTML-страницу, ориентируясь на представленный макет. Некоторые пиксельдрочерские дизайнеры даже проверяют вёрстку так: делают скриншот свёрстанной страницы в браузере и накладывают в режиме difference на дизайн-макет. Расхождений нет – значит, свёрстано хорошо, работа принимается.

Однако, не надо забывать и о том, что сайт не ограничивается вёрсткой. Чтоб сайт ожил, вёрстку надо натянуть на костяк программного кода, который будет выводить в HTML-шаблон переменные, которые надо в правильных местах отобразить. Это называется "интеграцией вёрстки". И тут может выясниться, что, казалось бы, крутой верстальщик на самом деле не очень крутой, потому что забыл про то, что вёрстку-то надо интегрировать. Так как я сам по себе верстальщик хреновый, и дизайнер вообще никакой, я не сравниваю попиксельно, что там попало, а что не попало, а сразу открываю HTML и смотрю в код. Бывалоча, я кричал: "что ты тут, блять, наверстал!?" - хотя всё выглядело идеально. А я усматривал проблемы в интеграции.

Итак, помимо того, чтоб верстать всё пиксел в пиксел, верстальщик должен помнить о том, что его вёрстку кому-то придётся интегрировать. Прежде всего, это означает, что вёрстка должна легко нарезаться на модули. То есть иметь отделяемые шапку и подвал, которые легко можно вынести в отдельные файлы, в них – легко выделяемые опять же в отдельные файлы меню и подменю, всякие баннеры, и так далее. Любой смысловой блок в вёрстке должен быть легко выделяем в отдельный файл, так как, скорее всего, он и будет выделен в отдельный файл. А если получается так, что в вынесенной части в зависимости от страницы то надо закрывать div, то не надо – это говно. Скрипт, который формирует, допустим, главное меню, не должен ничего знать о том, что надо там какие-то куски HTML показывать или не показывать в шаблоне в зависимости от каких-то внешних факторов. Он просто формирует пункты главного меню, прогоняет их через шаблонизатор, и возвращает кусок HTML, который вставляется в нужное место в лейауте страницы. Если там в зависимости от каких-то внешних условий меняется лэйаут, значит, надо сделать разные шаблоны! Каждый вырезаемый кусок HTML не должен влиять на сетку.

Пара истерик ведущего разработчика и скандалов в отделе, и верстальщик начинает думать об интеграции. Однако, всё равно ни верстальщики, ни веб-программисты до конца довольны работой друг друга не будут; тут главное – чтоб было взаимопонимание и все проблемы быстро разрешались.

Теперь что касается дизайнеров. Обычно дизайнеры рисуют то, что должно понравиться заказчику, чтоб он утвердил дизайн. После утверждения дизайн-макеты становятся первым дополнением к ТЗ и ты хоть убейся, но должен наверстать и напрограммировать так, как нарисовано. Осложняется это ещё и тем, что заказчики и дизайнеры само ТЗ читают крайне редко, и в итоге получаются утверждённые макеты, в которых полёт фантазии убрал какие-нибудь критичные части, которые есть в ТЗ, зато добавил новых очень красивых штуковин, функциональность которых в ТЗ не предусмотрена. Подходишь к арт-директору с вопросом: ну и чего вы тут нарисовали? А он пожимает плечами: "заказчик утвердил, за дизайн деньги заплатил. Пиздуйте, ребятки, въябывайте".

С этим надо бороться внутренним цензом. Дизайнер обычно слабо представляет, что можно быстро запрограммить, а что нельзя. Он думает, что "а, это просто можно сделать, что тут жмёшь, а тут шевелится", а разработчик отвечает, что это три дня надо программить. Или дизайнер думает, что вот такую фиговину сделать очень сложно, а разработчик говорит: "ну мы возьмём стандартный компонент, отрежем от него лишнее, это минут десять вместе с вёрсткой и её интеграцией". Поэтому дизайнер показывает разработчику, который точно ТЗ читал, дизайн перед тем, как отправить заказчику. Если у разработчика не шевелятся волосы на жопе от негодования из-за несоответствия дизайн-макетов техзаданию, значит, клиенту можно показывать.

И ещё есть один нюанс. Дизайнер обычно рисует идеальный случай. Когда название умещается ровно-ровно в отведённое для него место, когда текст не очень длинный и не очень короткий, а ровно-ровно в самый раз. Если верстальщик не спросит: а как это будет выглядеть, если у статьи не будет картинки? А если название будет очень длинное? А если текст будет очень большой или его не будет? А если тэгов будет много, и они залезут на название рубрики? - если даже он все эти вопросы не задаст и сверстает тот самый нарисованный и утверждённый идеальный случай, то программист, вы полагаете, об этом задумается? У себя на отладочной копии он набьёт тестовый контент из "фыва фыва" и "хуй123", проверит – выводится в шаблон всё, что надо? - выводится, и хорошо. А если даже замечает (хотя это вряд ли, конечно) что-то куда-то залезло, то ничего не перевёрстывает, а отмечает где-то в глубинах багтрекера: "что-то куда-то залезло", и считает свой долг выполненным. А потом, когда заказчик обнаруживает, что если написать название статьи длиннее ста символов, то едет вёрстка, то верстальщик уже должен править что? Правильно, интегрированный шаблон, по которому не по разу проехались программисты на бульдозере, везде торчат if, foreach, куча переменных, тернарные операторы и прочие прелести. Поди разберись в этой каше, которая только отдалённо похожа на первоначальную вёрстку, где тут надо что подправить.

3 комментария:

  1. Чую, накипел очередной говнопроект?:)

    С недавнего времени приходится пользоваться сайтами на asp.net - ненавижу всей душой.

    ОтветитьУдалить
    Ответы
    1. И не один проект, между прочим, накипел. А для программистов на ASP у меня отдельное проклятие. У одного из наших клиентов они делают сервер котировки с ядром расчёта, а мы пишем веб-морду типа тонкого клиента. Плюс ещё документация от них поступает крайне скудная и часто не вовремя, так что никогда такого не было, чтоб мы нормально всё запускали с первого раза и вовремя.

      Удалить
  2. Тут главное понимать, что ASP.NET уже умер и теперь вместо него ASP.NET MVC. А это мега-кошерный фреймворк (правда-правда), его сделал чувак, который работает сейчас в Github
    Его зовут Phil Haack.

    ОтветитьУдалить

Ублюдочный Гугл поломал форму комментариев. Извините.