Веб разработчику на заметку

Веб разработчику

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

Наверняка вам знакома ситуация, когда дизайнер не "додизайнил", верстальщик не "доверстал", в бэкенде легаси код, а ты отвечаешь за общий результат.

Начинать звонить в колокола нужно с самого начала, облегчив потом запуск, себе и команде. Так как же избежать этот самый "х:як-х:як и в продакшн" ?

Дизайн

Начиная с получения первых согласованных макетов страниц начинается реальная работа. На этом этапе очень важно обратить внимание на несколько моментов, перед тем как принять работу и передать дальше:

1) Максимально возможная тягучесть интерфейса, проверять нужно все элементы. У вас может быть форма, которая с виду отлично работает, на практике же, данных в ней будет больше, переработка полечёт лишнюю трату времени.

2) Требуйте иконки отдельно, лучше всего в SVG формате, если нет, то предпочтительней PNG высокого разрешения. Время не стоит на месте, 4K дисплеи уже стучатся в двери.

3) Favicon проекта должен быть в наличии в разрешением 144x144 px, сгенерировть из него кнопки и фавиконы, для всех современных железяк можно на Real Favicon Generator.

4) Вся графика, которую верстальщик не сможет отмасштабировать без потери качества, градиентами или повторениями, нужна в высоком разрешении отдельно. Макет — это просто набросок того, как всё будет выглядеть, создать действительно хорошую вёрстку, без хорошей графики — фронтенд разработчик не сможет.

Если этого всего не будет, верстальщик не будет особо против сделать работу и без этого "лишнего гемора". Этот момент нужно контролировать, и не давать никаких послаблений.

Фронтенд

1) Именование классов

Очень важно не привязывать названия блоков, к названию страницы. Если это форма контактов, то не следует называть селектор для формы или её элемента как например: ".form_contact". Сегодня это форма контактов, а завтра её скопипастят в другую часть проекта. Существует множестов слов: wide, medium, clear и т.д., чтобы описать форму, а не страницу на которой она находится.

БЭМ-методология обязательна для любого веб проекта, без неё вёрстка катится под откос.

2) Анимация кнопок

Если это обычный градиент, то кнопки не должны быть нарезаны в PNG, следует использовать CSS. Поможет сервис Сolorzilla. Если без порезки никак, то следует использовать спрайты. Для мелочи подойдёт base64 encoded PNG, прямо в стиле.

3) Масштабирование

Не у всех пользователей по умолчанию стоит 100% отображение страниц, это не очевидно, но люди активно используют +110%, +120 и т.д. масштабирование, это нужно контролировать сразу, вёрстка должна корректно работать во всех масштабах, не создавая лишних баг репортов.

4) Семантика

Когда подзаголовок h1 содержит на втором уровне h5, первый признак, что у нас проблемы. Не должны заголовки использоваться во всём сайте, только потому, что они дают жирный шрифт в 28px в нужном месте. Очень старая статья, которую написал Игорь Зенич всё ещё актуальна, читайте Вредную вёрстку.

Верстальщики в большинстве своём об этом знают, а вот т.н. Full Stack — нет. Чем раньше вы подсунете им нужную ссылку, тем лучше.

Достаточно просто понимать блочную модель1, тогда не будет никаких проблем и можно будет обойтись без жирных фреймворков.

5) Стайлгайды

Не следует экономить место, писать в строку, не оставлять отступов. Такая экономия никому не нужна, для dev версии вес кода не имеет значения, для готового продукта код всё равно будет пожат компрессорами, как CSS, так и JS.

6) Минимум инструментов

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

Сейчас у всех в голове Responsive Design, а я вот против! Лебедев у себя в Ководстве озвучил мысли с которыми я полностью согласен. CSS/HTML по умолчанию очень даже отзывчивы, ребята из Mrmrs даже создали страничку Fluidity, которая показывает необходимы на сегодня уровень отзывчивости.

Никакого CoffeeScript, новый слой абстракции усложняет дебаг, а следовательно и разработку. Хорошо об этом написал Jeff Walker в своей статье СoffeeScript Is Not The Answer. Кофи скрипт это игрушка, не более того.

Тоже самое касается и HAML, режет правду-матку Kirill Zubrovsky в своей статье No More Haml or CoffeeScript.

Хотите быстрее набирать? Используйте Emmet, я — пас.

Ещё хорошо бы не запихивать jQuery везде где только можно, очень часто достаточно нативных возможностей JS. Можно распечатать простыню и повесить на стену You Might Not Need jQuery.

Бэкенд

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

1) Легаси код

Враг номер один, его можно победить только одним способом — всё переписывая.

Это главная мысль, которую я вынес из этого проекта. К сожалению невозможно выехать, написанием одних лишь новых частей системы, не влезая в другие. И хотя core у нас в брокере переведен на onPHP, мы готовы писать новые части системы нормально, но от этого в конечном итоге легче не стало.

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

2) Документирование

Моя позиция неизменна, хороший код документировать нужно редко, плохой код нужно не документировать — его нужно переписывать. Чем раньше появится Wiki, тем лучше, если её не будет, то уж точно, примеры, подходы, решения и т.д. никто не задокументирует, а тем более не прочтёт.

3) SQL

Во первых при добавлении новых полей, чтобы старые запросы не стали колом, хорошо бы по умолчанию все новые поля, которые добавляются — сразу объявлять как NULL. Это нас коснулось, но не сильно.

А ещё призываю не использовать ENUM типы в MySQL, от них только головная боль, подробнее на StackOverflow.

4) Пакетные менеджеры

Будь то pip, composer или gem, чем раньше вы выпилите сторонние библиотеки из репозитория, тем лучше. Ну или как минимум не стоит мусорить там, где работаешь.

5) Деплой и сборка

Многие начинают тащить grunt, gulp и ещё вагон инструментов. Я даже умудрился в одном из проектов использовать ant, со сборочным скриптом от Boilerplate.

Это оверхед в большинстве случаев. В Unix мире 37 лет назад написали make, до сих пор нет ничего лучше. Поэтому один раз пишем Makefile, ставим в крон и забываем о сборке как о страшном сне. У нас в проекте Makefile подтягивает последнюю версию из Git репозитория, катом4 автоматически собираются JS и CSS скрипты в один файл, компрессор жмёт их, после чего файлы становятся доступны в веб.

Ссылки

О читаемоcти кода у меня в блоге.

Вменяемые правила для CSS кода написали в Google.

Годный JavaScript код у Airbnb.

Метод .end() в jQuery улучшает читабельность и сокращает количество кода.

Pep-8 в Python.

Правильный путь в PHP.

Заключение

Именно от части всех этих мелких на первый взгляд проблем, проекты не завершаются никогда. Старый плохой код, который не переписан вовремя — сродни бомбе замедленного действия.

Новый разработчик не может его осилить; миддл не может нормально писать, страдая параличем анализа 2; опытный разработчик может, но не хочет.

В общем с мыслями: — Ну теперь то точно всё сделаем правильно.

Вперёд, на новые грабли!


  1. WTF, HTML and CSS? 

  2. Подробнее о параличе анализа Scott Hanselman у себя в блоге, а также перевод на habr

  3. Полный перевод Zen

  4. имеется в виду Unix утилита. 


comments powered by Disqus