Я сверстал сайт по готовым макетам так, чтобы он работал как задумано: элементы стояли по сетке, ровно, отзывчиво и оттипографировано. Сам сайт: nopain.help

Закончили работу вовремя, но без проблем не обошлось: на проект ушло вчетверо больше времени, а под капотом у релизной версии бардак, который невозможно поддерживать.

Расскажу, что я теперь бы сделал иначе.

Заложить больше времени

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

Речь не о «просто сверстать», «инфосайт с парой страниц, тут работы-то на вечер» или типа того. Мне из-за этого пришлось потратить на проект три лишних ночи. Так себе удовольствие.

Я плохо справляюсь с оценкой фронтендовых задач, но сейчас взял бы самую пессимистичную оценку, увеличил вдвое и выдал за оценку. На всякий случай.

Продумать шаблон сайта

Базовый лейаут должен быть один и спроектирован так, чтобы удовлетворять всем страницам сайта. Везде одни принципы, одни универсальные классы, один фреймворк.

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

Принципы чистоты и единой ответственности применимы и для структуры страницы. Стоит применять их так же, как и на бекенде.

Думать об отзывчивости

Как себя ведёт сайт при изменении ширины окна браузера, нужно узнать заранее. Такое поведение бывает небанальным: сайт может тянуться, складываться, меняться вёрстка.

Я об этом не подумал, поэтому долго добивался того, чтобы разные блоки сайта тянулись параллельно. Для этого мне пришлось с нуля переверстать меню и страницу статьи: без этого они тянулись неравномерно и сетка рушилась при изменении ширины окна.

Сейчас я бы прошёлся по макетам вместе с дизайнером и подробно расспросил об отзывчивости. Это поможет правильно составить структуру и точнее оценить фронт работ.

Сделать мобильную версию

Посетители заходят на сайт с мобильных устройств. Если сайт не работает или приходится постоянно менять масштаб, пользователь едва ли почувствует заботу и уважение. Если мобильной версии нет в плане работ, стоит предложить простой вариант самому.

Мы делали мобильную делали в последние часы перед релизом. Поняли, что не успеваем и отказались. Вроде бы ничего страшного: в изначальной постановке задачи мобильной не было. Теперь сайт неудобно читать со смартфона.

Разработчик сам узнаёт, планируется ли мобильная версия. Если не планируется, сам предлагает дешёвое решение. Сайт без мобильной версии — чемодан без ручки.

Автоматически тестировать

Проверять, что и где не соответствует макету, должен робот. Не дизайнер и не разработчик. Если это будет делать человек — он обязательно что-нибудь пропустит. Не по невнимательности, а потому, что комбинаций браузеров и устройств слишком много и не все есть под рукой.

У меня не было широкого экрана, поэтому я не мог проверить поведение сайта при ширине в 1920 пикселей. Сначала я использовал для этого сторонние сервисы, но они обманывали. Потом использовал дизайнера. Было так: «а сейчас? — не, 5 пикселей вправо — а сейчас? — теперь 2 влево — теперь? — всё равно не то». Это раздражало.

С самого начала стоит настроить подобное тестирование, это сэкономит много времени на проверке. Использовать можно, например, PhantomCSS.

Использовать препроцессор css

Стили подчиняются тем же правилам, что и хороший код: в них нет копипасты и есть понятные названия и хорошая структура. Поэтому стоит использовать препроцессор.

Иначе при необходимости сменить какой-нибудь отступ с 15 на 20 пикселей придётся пройтись по всем пятнадцатипиксельным отступам и решить, нужно ли его менять. Я несколько раз ошибся. Привет, мистер «несколько-лишних-часов-работы».

В качестве таких препроцессоров можно использовать, например, Saas, Stylus или Less.