Команда из агентов Смитов или мысли о том, как писать и поддерживать фронтенд высоконагруженного проекта

Вы когда-нибудь задумывались над тем, как бы было круто для интернет проекта в целом, если бы весь код писали клоны одного и того же человека? Идеальная команда, которая думает одинаково, ставит пробелы и переносы строк в одном и том же месте, пишет цвета в HEX только с прописными буквами и вообще делает все идентично.

Что-то вроде самокопирующегося агента Смита из Матрицы. И представьте что это возможно...

Предисловие

Всем привет! Чтобы было понятно пару слов о моей работе и кто я вообще.

Меня зовут Канат и я фронтенд-разработчик (или попростому верстальщик) в агентстве “Кликобилие”, которая является одним из направлений нашей компании, в которую входят Prodengi.kz, Кликобилие, Кредит24 и МастерТаргет Казахстан.

Хоть моя задача заключается в написании одностраничных продающих страниц, но все же время от времени я хожу в “гости” к коллегам-программистам из Prodengi и вижу, а иногда и участвую в процессе поддержки высоконагруженного портала.

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

И бичом всех команд разработки является поддерживание командного стиля и стандартов. Потому что когда все пишут так, как им удобно, через месяцы код превращается в кровавое месиво, над которым остается только плакать и материться.

Так как я верстальщик, то я сейчас буду расписывать все на примере фронтенда, но идеи скорее всего можно и перенести на другие уровни.

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

Представьте себе…

Давайте возьмем два проекта “вилларибо” и “виллабаджо” (ссылка для тех кто не врубился)

Представьте себе проект “виллабаджо” в зачатке.

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

Проект растет, заказов на рекламу и спецпроекты много, приходится взять еще одного разработчика. В это время все еще нет разделения на фронтенд и бэкенд, оба разработчика на все руки мастера. И начальство считает это само собой разумеющимся.

Но проблема в том, что эстетические предпочтения у нового разработчика другие. Ему нравятся компактные, но яркие кнопки, межстрочные интервалы у него по 1,2em. И эти мелкие детали вносят самый первый беспорядок во внешнем виде проекта. Это все не говоря уже о коде.

А теперь представьте, что каким-то чудесным образом проект развивается дальше, разработчики прибавляются. Теперь их уже пятеро. Есть какое-то условное разделение на фронтенд и бэкенд. То есть те, кто работают дольше занимаются “интересным” бэкендом, а новички возятся с версткой.

Код проекта превратился в мешанину, там и сям валяются старые блоки, которые просто закомментировали, авось пригодится, но о нем уже не вспоминали года полторы. Все стили “валяются” в одном огроменном файле на 200Кб. Нет каких либо унивицированных стилей. Каждый раз, когда надо вставить куда-то кнопку, стили для него копируются и вставляются в новый селектор, нет никакого наследования и расширения стилей. О чистоте кода никто даже и не задумывается. Все матерятся, плачут, но все равно пишут также прибавляя к имеющемуся еще больше говнокода.

Я немного утрирую, но вы наверно представили себе какая “ж...” творится во фронтенде “виллабаджо”.

Другая сторона

А теперь представьте проект “вилларибо”.

С самого начала основатель проекта имел опыт в разработке и решил пойти по “светлой стороне”. Он обратился в дизайн студию, ему сделали дизайн, его утвердили. И плюс он доплатил за то, чтобы ему создали дизайн гайд. То есть один стиль для всех возможных элементов на сайте, которые вообще могут появиться: кнопки, стрелки слайдеров, ссылки, навигация, заголовки, цитаты, одним словом всего.

Для этого в студии просто взяли UI-kit Bootstrap и стили всех элементов переделали под дизайн проекта. Гайдлайн включал конкретные рекомендации вплоть до размеров шрифта в заголовке h5, отступам, цветам и пр.

После этого наняли сразу двух разработчиков: верстальщика фрилансера на проектную работу и бэкенд-разработчика на постоянку.

Верстальщику дали месяц на то, чтобы он сверстал все макеты страниц и элементы по гайду, который составила дизайн студия. И оказалось, что они наняли хорошего верстальщика, который знаком с методологиями написания стилей: SMACSS, BEM, OOCSS. И на основе этих методологий он создал свою архитектуру фронтенда, конкретно для этого проекта, по пути все документируя.

Он разделил стили на несколько уровней по SMACSS+BEM:

• переменные цветов, шрифтов, z-index’ов, гридов и прочих…
• ресет + базовые стили
• гридовая система, и все возможные вариации лейаута (с сайдбаром, без сайдбара и т.п.)
• все модули на сайте от кнопок, до полей форм и заголовков, сюда же он включил состояния этих модулей (т.е. объединил modules и states из SMACSS и модификаторы из BEM)
• и в конце все стили, которыми пришлось расширять стандартные классы (вероятность этого должна стремиться к нулю и жестко контролироваться с помощью ревью кода).

Допустим все селекторы были написаны на BEM, указаны стандартные модификаторы. А после, того как были написаны все элементы и сверстаны все страницы сайта, была создана страница, где были представлены эти элементы и их разметки, чтобы новому верстальщику можно было просто копировать и вставлять куски кода и получать необходимые элементы страницы.

Но суперверстальщик не остановился на этом. Он пишет документацию, по которому все верстальщики, которые будут после него должны использовать одну рабочую среду Webstorm от JetBrains. И это не прихоть, потому что специально для этой рабочей среды он написал пакет сниппетов для каждого элемента из гайда.

То есть верстальщику, который придет после него даже не надо будет копировать куски кода и вставлять, ему всего-то и нужно нажать комбинацию btn+Tab в файле html, чтобы  у него появилась разметка кнопки, со всеми классами кнопки.

Насчет стандартов написания кода он тоже позаботился, указав, что для стандартизации необходимо использовать beautifier’ы вроде CSSComb и написал конфиги для них, чтобы код всегда приводился к одному стадарту.

После этого верстальщик-фрилансер сдает работу, основатель проекта выплачивает ему крупный одноразовый гонорар и отдает документацию разработчику, который на полной ставке.

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

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

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

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

Итоги

Если подводить итоги, то комбинация из грамотной архитектуры, стилевого гайда, возможности написания сниппетов и жесткого контроля над стандартами написания кода сделают проект легким в поддержке, масштабировании и гибким к изменениям, которые могут в будущем его коснуться.

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

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