Я сверстал сайт по готовым макетам так, чтобы он работал как задумано: элементы стояли по сетке, ровно, отзывчиво и оттипографировано. Сам сайт: nopain.help
Закончили работу вовремя, но без проблем не обошлось: на проект ушло вчетверо больше времени, а под капотом у релизной версии бардак, который невозможно поддерживать.
Расскажу, что я теперь бы сделал иначе.
Заложить больше времени
Времени не хватит. По дороге добавятся функции, правки будут бить струёй, старый код не будет согласовываться с новым, что-то придётся перевёрстывать, а что-то — удалять.
Речь не о «просто сверстать», «инфосайт с парой страниц, тут работы-то на вечер» или типа того. Мне из-за этого пришлось потратить на проект три лишних ночи. Так себе удовольствие.
Я плохо справляюсь с оценкой фронтендовых задач, но сейчас взял бы самую пессимистичную оценку, увеличил вдвое и выдал за оценку. На всякий случай.
Продумать шаблон сайта
Базовый лейаут должен быть один и спроектирован так, чтобы удовлетворять всем страницам сайта. Везде одни принципы, одни универсальные классы, один фреймворк.
В моём случае на странице было три блока, каждый из которых жил своей жизнью. Из-за этого изменений было втрое больше. Хедер пришлось несколько раз переделывать. Отступы постоянно переставали согласовываться. Время на проверку увеличивалось. Брр.
Принципы чистоты и единой ответственности применимы и для структуры страницы. Стоит применять их так же, как и на бекенде.
Думать об отзывчивости
Как себя ведёт сайт при изменении ширины окна браузера, нужно узнать заранее. Такое поведение бывает небанальным: сайт может тянуться, складываться, меняться вёрстка.
Я об этом не подумал, поэтому долго добивался того, чтобы разные блоки сайта тянулись параллельно. Для этого мне пришлось с нуля переверстать меню и страницу статьи: без этого они тянулись неравномерно и сетка рушилась при изменении ширины окна.
Сейчас я бы прошёлся по макетам вместе с дизайнером и подробно расспросил об отзывчивости. Это поможет правильно составить структуру и точнее оценить фронт работ.
Сделать мобильную версию
Посетители заходят на сайт с мобильных устройств. Если сайт не работает или приходится постоянно менять масштаб, пользователь едва ли почувствует заботу и уважение. Если мобильной версии нет в плане работ, стоит предложить простой вариант самому.
Мы делали мобильную делали в последние часы перед релизом. Поняли, что не успеваем и отказались. Вроде бы ничего страшного: в изначальной постановке задачи мобильной не было. Теперь сайт неудобно читать со смартфона.
Разработчик сам узнаёт, планируется ли мобильная версия. Если не планируется, сам предлагает дешёвое решение. Сайт без мобильной версии — чемодан без ручки.
Автоматически тестировать
Проверять, что и где не соответствует макету, должен робот. Не дизайнер и не разработчик. Если это будет делать человек — он обязательно что-нибудь пропустит. Не по невнимательности, а потому, что комбинаций браузеров и устройств слишком много и не все есть под рукой.
У меня не было широкого экрана, поэтому я не мог проверить поведение сайта при ширине в 1920 пикселей. Сначала я использовал для этого сторонние сервисы, но они обманывали. Потом использовал дизайнера. Было так: «а сейчас? — не, 5 пикселей вправо — а сейчас? — теперь 2 влево — теперь? — всё равно не то». Это раздражало.
С самого начала стоит настроить подобное тестирование, это сэкономит много времени на проверке. Использовать можно, например, PhantomCSS.
Использовать препроцессор css
Стили подчиняются тем же правилам, что и хороший код: в них нет копипасты и есть понятные названия и хорошая структура. Поэтому стоит использовать препроцессор.
Иначе при необходимости сменить какой-нибудь отступ с 15 на 20 пикселей придётся пройтись по всем пятнадцатипиксельным отступам и решить, нужно ли его менять. Я несколько раз ошибся. Привет, мистер «несколько-лишних-часов-работы».