Здравствуйте, меня зовут Александр Зеленин, и я веб-разработчик.
Многократно я слышал мнение, что верстка — удел начинающих frontend’еров. Хотя фактически это важнейшая часть любого (почти) веб-проекта. Это то, что пользователи видят в первую очередь. На текущий момент качественная вёрстка (особенно проектирование блоков) в крупном проекте требует большого количества различных навыков.
В данной статье представляю схему развития верстальщика
[большая по клику]
Само собой, это не всеобъемлющая и единственно верная схема. Есть ещё целая гора связанных навыков, релевантных технологий и так далее. Градация является субъективной.
Хочу сразу добавить, что конкретных ссылок на учебные материалы в статье не будет. Буду рад дополнениям в комментариях.
Чего мы ожидаем?
В первую очередь необходимо понять, чего мы ожидаем от человека на каждом из уровней. Ваши ожидания могут отличаться.
Junior — знает основные теги, может подправить контент на готовом html сайте, умеет грамотно форматировать текст, без проблем вставит встраиваемый элемент (ролик с ютуба, яндекс карту), ведёт работу через систему контроля версий только для себя (master, 1 контрибьютор). Может сверстать что-то несложное с нуля, и оно даже не поедет (лично у него). В целом не является самостоятельной единицей и требует руководства свыше.
Middle — более-менее автономная единица (либо полностью автономная для малых и средних проектов). Может хорошо сверстать сайт средних размеров, и он будет корректно отображаться во всех актуальных версиях браузеров. Понимает, как работают шаблонизаторы, и может их использовать (при условии предоставления остального кода). Умеет планировать и документировать свою работу и оценивать сроки. Понимает важность поддержания стиля кода. Понимает, зачем есть грид-системы и css фреймворки. Умеет брать всю необходимую информацию из макетов от дизайнера. Может взаимодействовать с небольшой командой, создавать ветки и пулл-реквесты.
Senior — может спроектировать систему блоков для крупного проекта. Знает, как избежать повторов и проблемных мест при использовании его кода другими разработчиками. Умеет декомпозировать сложные задачи и грамотно формулировать задачи. Умеет применять минимум одну методологию разработки (например, БЭМ). Может сделать так, чтобы проект открывался максимально быстро. Хорошо понимает несколько популярных шаблонизаторов. Способен написать сборщики и автоматизировать процесс, с этим связанный. Может проводить код ревью и курировать других верстальщиков.
Рассмотрим теперь чуть конкретнее, что включает в себя каждый из блоков на каждом уровне.
Junior
HTML — знание основных тегов, аттрибутов. Понимание, как его писать в принципе.
Типографика — умение отформатировать текст. Текст — основа практически любого проекта. Вставка неразрывных пробелов где надо, выделение жирным, курсивом, abbr и так далее. Можно использовать типограф или схожий сервис, но уметь понимать результат.
Семантика — понимание, что для определённых задач есть определённые теги. Уметь выбрать нужный тег.
Медиа — какие виды медиа можно встраивать в страницу.
Iframe — встраивание сторонних виджетов (видео, аудио, карты и т.п.).
Аудио, Видео — можно отложить изучение, т.к. частично решаются с помощью iframe. Понимать, какие форматы умеет воспроизводить браузер, как оформить плеер и так далее.
Картинки — какие графические форматы и в каком виде воспринимает браузер. Плюсы и минусы использование тех или иных форматов.
Растр — jpg, png, gif. Понимать различие форматов и уметь применять что и где надо.
SVG — можно отложить изучение, т.к. применяется реже, чем хотелось бы. Понимать плюсы, минусы, ограничения и т.п.
Шрифты — можно отложить изучение. На самом деле довольно сложная тема, и в общем случае я бы советовал начинающим использовать системные шрифты. Уметь подгрузить шрифты, оптимизировать отображение, минимизировать лаг отрисовки с кастомными шрифтами.
Табличная вёрстка — опционально. Для желающих верстать качественные email-рассылки в будущем.
CSS 1 — шрифты, цвета, выравнивание, размеры.
CSS 2.1 — управление поведением блоков, позиционирование, полноценное оформление.
Селекторы — простые селекторы на тег, класс, вложенный элемент. Простые псевдоселекторы типа :hover.
Именование — как называть классы, чтобы не было мучительно больно.
Блочная вёрстка — разбить картинку на осознанные блоки, воплотить блоки в HTML, оформить с CSS.
Браузеры — можно отложить изучение. Какие браузеры существуют, в чём их различие.
Инструменты разработчика — можно отложить изучение. Использовать инструменты браузеров, чтобы разбираться в проблемах отображения.
Текстовые редакторы — какие текстовые редакторы для разработчиков есть и зачем. SublimeText и Notepad++ приведены для примера, как хорошо мне знакомые. Уметь настраивать в них базовые вещи, такие как отступы, перенос строки и так далее.
Системы контроля версий — я лично считаю умение их использовать хотя бы индивидуально, лично для себя, очень важным. Понимать, для чего эти системы созданы и какие бывают.
Git — понимать в общих чертах задачу и принципы самой популярной системы контроля версий.
Github / bitbucket — уметь использовать одну из популярных площадок для git.
Checkout / commit / push / pull — базовые операции для личного использования.
Stash — для временного сохранения ненужных в данный момент данных.
10 работ — сделать минимум 10 работ в различном дизайне. Можно тестовых, это не важно. Важно, чтобы полноценных в рамках текущих знаний.
Middle
CSS 3 — градации, тени, сглаживание, фильтры, трансформации.
Продвинутые селекторы — элементы, следующие за опделённым (+), определённый по счёту (nth-child), shadow-dom, before/after и так далее.
Анимации — опционально. transition и animation. Плавные переходы, анимации. Понимать ограничения и минусы.
Сетки — зачем существуют, как выстраивать, какие есть готовые решения. Для примера можно посмотреть Flexbox grid или любой другой, который найдёте.
Фреймворки (CSS) — зачем нужны, как применять. Желательно научиться хорошо использовать минимум один. Очень пригождается для прототипирования. Значительно повышает качество проекта при отсутствии бюджета на дизайн (не уникально, но юзабельно).
CSS препроцессоры — можно отложить изучение. Оптимизация работы, более красивый и читабельный код. Переменные, миксины и т.п. Поработать с одним или несколькими популярными препроцессорами типа SASS, LESS, Stylus.
Media queries — можно отложить изучение. Отображение нужных стилей в зависимости от условий (устройство, размер экрана, плотность пикселей, версия для печати и т.п.).
Стиль кода — понять, для чего есть соглашения по стилям, изучить и начать применять любой (рекомендую от AirBNB).
DRY / KISS / SOLID — можно отложить изучение. Понять важные принципы разработки, ощутимо упрощающие дальнейшее сопровождение проекта.
OOCSS — опционально. Понять, что есть объектно-ориентированный css и для чего он. В том или ином виде используется во многих проектах (хоть и без понимания, что это он). В идеале, научиться проектировать. Может отлично зайти для крупных проектов.
Документация — понять, что и как документировать. Документировать. Можно отложить, но в будущем обязательно изучить разметку markdown.
Планирование — научиться оценивать сроки по картинке и определять последовательность работ.
Декомпозиция — можно отложить изучение. Научиться разбивать задачу на подзадачи. Это сложнее, чем кажется :-)
Постановка задач — можно отложить изучение. Научиться чётко описывать задачи текстом так, чтобы другие разработчики, в том числе с меньшей квалификацией, достаточно однозначно понимали, что необходимо сделать для их выполнения.
Flexbox — понимание модели, умение применять полноценно.
Вёрстка писем — опционально. В целом навык не лишний. Понимать особенности почтовых систем, сохранить хороший внешний вид и не упасть в спам (если это не спам).
Полифилы — разобраться, как использовать самые актуальные возможности разработки, сохраняя обратную совместимость. Понять минусы и плюсы от такого подхода.
Кроссплатформенная вёрстка — понимать, что нужно делать, чтобы проект хорошо выглядел не только под Windows, Linux и Mac, но и под SmartTV или PS.
Кроссбраузерная вёрстка — понимать разницу рендера браузеров и заставлять их показывать одинаково. Сайт CanIUse очень помогает в этом.
Мобильная вёрстка — можно отложить изучение. Понимать, какие ограничения несут в себе мобильные платформы. Использовать лимитированное пространство грамотно.
Оптимизация — можно отложить изучение. Разобраться в «цене» тех или иных приёмов. Понять, из каких фаз состоит отображение сайта пользователю.
Загрузка — можно отложить изучение. Оптимизации, связанные с размером, кешем, сжатием, объединением ресурсов и т.п.
Отрисовка — можно отложить изучение. Оптимизации, связанные со скоростью рендера после загрузки.
SEO — можно отложить изучение. Хотя бы базовое понимание работы поисковых систем. Умение «помочь» поисковой системе разобраться, куда смотреть и что важно.
Шаблонизаторы — разобраться, каким образом можно переиспользовать код, группировать элементы и компоновать страницы. Очень желательно изучить как серверный рендеринг, так и клиентский. Сюда же входят шаблоны на «чистом» языке (типа простых PHP вставок). Работа «до» (dataflow) шаблонизатора нас не интересует.
PHP — можно отложить изучение. Разобраться в базовом синтаксисе и уметь внести мелкие правки, связанные с оформлением страницы.
CMS — можно отложить изучение. Узнать, какие CMS существуют и для чего они были созданы. Научиться писать шаблоны хотя бы для одной (рекомендую Wordpress).
Javascript — можно отложить изучение. Изучить базовый синтаксис, понять, как вешать простейшие обработчики и проводить простую работу с DOM.
jQuery — можно отложить изучение. Научиться экономить кучу времени для решения довольно типовых задач с использованием плагинов для самой популярной js библиотеки (после vanilla.js, конечно).
NodeJS — можно отложить изучение. Разобраться, как запустить простейший сервер, раздавать статику и рендерить на стороне сервера. Можно использовать Express или любой другой фреймворк.
Сборка — опционально. Научиться собирать проект из кучи CSS / HTML файлов в то, что нужно. Рекомендую ознакомиться хотя бы с grunt и gulp, как представителями «разных» лагерей.
IDE — опционально. Изучить, зачем нужны IDE и как их использовать. Перейти на использование какого-либо IDE для экономии времени. Важно: изучение IDE сравнимо с полноценным изучением языка программирования, и вкладывание большого количества времени в это может не оправдаться. Лично я пользуюсь текстовыми редакторами (и только для ооочень крупных проектов включаю IDE).
Branching — научиться управлять ветками в git.
Merge — научиться сливать ветки с разрешением конфликтов.
Fetch / Rebase — разобраться, зачем они, когда их применять, и начать применять по необходимости.
Графические редакторы — разобраться, какие бывают, для чего. Чем векторные отличаются от растровых. Важно понимать редактор хотя бы на уровне «чтения» макета от дизайнера. Выбрать правильный шрифт, размер, цвет и т.п. Чтобы не на глаз, а точно. Рекомендую поработать минимум с 1 растровым (Photoshop) и 1 векторным (Figma).
50 работ — к концу этапа у вас порядка 50 различных работ, демонстрирующих навыки из изученных областей.
Senior
Хоть на схеме и кажется маленькой эта группа, но фактически она самая большая. Т.к. к этому моменту необходимо изучить всё то, что откладывалось.
Адаптивная / Отзывчивая вёрстка — разобраться в высшей ступени и скомбинировать все полученные до этого знания. Проект должен выглядеть хорошо везде и на всём (в рамках разумного).
Постепенная деградация / Прогрессивное улучшение — понять, что это и зачем. Использовать.
Gitflow — уметь объяснить другим разработчикам, как создавать ветки, куда их вливать, как, уметь провести код ревью (вёрстки, само собой, не кода).
БЭМ — опционально. Разобраться в методологии, позволяющей создавать безлимитно крупные проекты так, чтобы при минимальной синхронизации различные команды могли использовать блоки друг друга. Есть и другие методологии, дающие не худший результат. К этому моменту о них вы так или иначе будете знать и сможете, при желании, изучить.
100 работ — иметь суммарно сотню работ, демонстрирующих различные полученные навыки. На самом деле, это всё условно. Можно иметь одну работу (состоящую из различных частей) в портфолио, которая уже покажет, что вам ничего не страшно.
Заключение
Фактически многие из этих тем небольшие. Однако держать кучу различных факторов в голове очень сложно. За 15 лет я общался менее чем с десятью верстальщиками (да и вообще программистами), которых отнёс бы к категории Senior (верстальщиков, программистов хороших было сильно больше).
Навскидку – на полноценное изучение и практику только вёрстки с нуля вполне можно затратить год (и более, если уходить в проектирование компонентов).
Надеюсь, тем, кто находится в начале пути, схема подскажет, куда можно ещё двигаться, и что не обязательно сразу (а можно и вообще не двигать в него) бежать в программирование.
Также планирую создать полноценный бесплатный курс с подробным рассмотрением каждой из тем-прямоугольников со схемы. Буду рад предложением, отзывам, пожеланиям и так далее.
Курс, вероятно, будет в формате видеоуроков с полным текстовым и графическим дублированием. Если дело пойдёт, приложу в будущем ссылки в комментарии.
upd
Много сообщений о том, что верстальщик без знания фреймворка не нужен. В основном это пишут разработчики в крупных проектах. И, для них, это вполне так. Но есть ещё много студий делающих лендинги, различные шаблоны для вордпресов и других CMS. Это вполне себе хороший рынок и возможность зарабатывать. Есть довольно много совершенно небольших проектов, с гораздо меньшими требованиями, которые верстальщик способен закрыть на отлично.
Комментарии (131)
kartvladek
04.01.2018 12:27+2Жутко субъективная статья. Почему к примеру Джуниору сразу не вникнуть в Бутстрап (и иже с ними)? Что в этом сложного для него? Позабавило упоминание почему-то Вордпресса после 100 работ (на картинке) — раньше нельзя?) И без него тоже никак? В силу излишней субъективности как пособие я бы не стал рекомендовать этот материал
Zav Автор
04.01.2018 12:391. Да, субъективная. Об этом даже говорил. Не субъективно это не решить никак.
2. Можно сразу вникнуть в бутстрап. Даже сразу его использовать. Но при необходимости доработки за пределами бутстрапа могут возникнуть проблемы. Бутстрап, таки, это частный случай. Каждый сам для себя выбирает что изучать.
3. Вордпресс можно и раньше, а можно и без него (он помечен как опциональный на схеме и в тексте). И не после 100, а после 50. Числа эти могут быть так же другими (о чем есть в тексте).
Буду рад увидеть какую-либо схему с разделением по градациям не являющуюся субъективной. Спасибо.
romy4
04.01.2018 12:27+1Почему приведён только один способ именования БЭМ? Это не стандарт де-факто.
Zav Автор
04.01.2018 12:40Приведено 2 способа именования — OOCSS и БЭМ.
Это могут быть и другие стандарты, но эти являются одними из самых распространённых и хоть сколько то признаны.
И даже они идут как «опциональные» на схеме.
dom1n1k
04.01.2018 13:01+1БЭМ только для синьора и то опционально? Окееей
Zav Автор
04.01.2018 13:03Поделитесь, как видите картину вы.
Ozonix
04.01.2018 13:43+1Скажу честно, для верстака может быть и да, однако соглашусь с dom1n1k — сомнительно.
БЭМ — это минимум из методологий которые должен «знать» джун, и хотя бы полноценно ей владеть. А с мидла уже начинать понимать что это не высеченные на камне заветы, и не стоит как прилежный ученик юзать их символ в символ как в книжке.
Мидл — это старшекурсник гильдии творцов. Он и сетку сам наколдует, и префиксные заклятия наложит и зарисует это в своей css-книжке словом что джун поймет, да и сеньор похвалит)
Если грубо, БЭМ — это некая основа как типа знать три кита ООП. Он показывает как должно быть, но нигде в больших проектах нет чистой БЭМ.Zav Автор
04.01.2018 13:46Тут есть разница в требованиях. Я по этому свои требования и описал в начале статьи.
Я раньше тоже от джунов требовал БЭМ. Как начал нанимать людей, понял что картина совершенно иная. И то понимание БЭМ у новичков ценности не имеет практически.
В целом для новичка довольно хорошим результатом является осознанно называть классы, а не .topLeftBlock
Так же добавил блок upd. в статью. Делая, например, лендинги для разных компаний, БЭМ не нужен и даже вреден, т.к. нет переиспользования компонентов.Ozonix
04.01.2018 14:00+1Все верно, здесь в статье больше придирки к проф уровням. Просто «задаунгрейдь» требования к методологиям хотя бы до мидлов, а вместо них, чтоб не пустовало место скиллов для сеньоров, добавь паттерны проектирования)
Zav Автор
04.01.2018 14:11Я для мидлов добавил OOCSS. Как по мне так это довольно крутая и более универсальная методология, нежели БЭМ. Во всяком случае оно лучше применимо на маленьких и средних проектах.
Паттерны проектирования… это уже не для верстальщиков. Я добавил DRY, KISS, SOLID, т.к. изучая их в каком-то виде можно лучше компоновать блоки, но что-то прям такое серьёзное должен делать не верстальщик уже.
YemSalat
05.01.2018 10:25И то понимание БЭМ у новичков ценности не имеет практически.
В целом для новичка довольно хорошим результатом является осознанно называть классы, а не .topLeftBlock
Мне кажется у вас в статье просто нет четкого обозначения понятия «верстальщик».
Если воспринимать это как совсем отдельную профессию, то сомневаюсь что кому-то будут действительно нужны джуниоры и возможно даже мидлы которых вы описали. Разве что в качестве бесплатных стажеров (иначе могут просто мешать, т.к. придется им все объяснять и возможно даже переделывать после их «работы»)
Знакомые недавно как-раз искали «чистого» верстальщика на проект (single-page app, Angular2). Градации на джунов и т.д. там не было, но основные требование к кандидату были примерно такие:
— HTML5/CSS3, Mobile-first/Responsive, Transitions/Animations, Flexbox
— LESS/SASS (куда без них сейчас в более-менее крупных проектах)
— знание Ангуляра или Реакта (разумеется только на уровне необходимом для верстки)
— гит/гитхаб
— знание всех основных инструментов для фронта: npm/gulp/webpacк и т.д.
— предпочтительно: — знание основ работы с юниксом
— предпочтительно: — опыт с Д3
Под эти требования даже описанный вами сениор может не подойти. А что будет делать на работе ваш джуниор — мне вообще трудно представить, честно говоря.
Кроме того, мне кажется у вас есть несколько 'немного устаревших' пунктов. Например, jQeury и Wordpress с каждым днем становятся все менее востребованы, стоит ли тратить время на их изучение? Возможно лучше потратить его на более глубокое изучения основ HTML/CSS/JSYemSalat
05.01.2018 11:31-2PS Кстати, если кому-то в спб нужна сейчас работа верстальщика (согласно требованиям описанным выше) — пишите в личку.
anttoshka
05.01.2018 12:58Wordpress конечно же не обязателен, а вот jQuery — очень даже. Но только если речь идет о создании сайтов, на которых не используются какие-либо фреймворки.
Zav Автор
05.01.2018 13:19Почему же? В начале есть описание чего может верстальщик того или иного уровня.
Ну и я не говорил что это обязательно отдельный человек.
jQuery есть в каждом втором проекте. По Wordpress'у настолько нет работ, что всего 8871 открытых вакансий на апворке с тегом wordpress.
Для понимания — по реакту 1307.
На самом деле это разного рода работы, надо понимать, но игнорировать реальный пулл вакансий несколько странно.YemSalat
05.01.2018 14:56На самом деле это разного рода работы, надо понимать, но игнорировать реальный пулл вакансий несколько странно.
Ну тогда скажите на какую работу вы бы наняли «дхуниора» из вашего списка? (за 20000р/мес как вы ниже предлагаете)
По Wordpress'у настолько нет работ, что всего 8871 открытых вакансий на апворке с тегом wordpress.
Для понимания — по реакту 1307.
Посмотрите графу `Est. Budget` в ваших списках и увидите что соотношение прямо противоположное.
С апворком не работал, честно говоря, насколько я понимаю — это биржа для фрилансеров. Я думал что речь скорее про работу в офисе / на зарплате.
На headhunter'е:
wordpress — 106 hh.ru/search/vacancy?text=wordpress&area=1
react — 507 hh.ru/search/vacancy?text=react&area=1
Опять же, полностью противоположная ситуация.
Я считаю время Wordpress и jQuery уходит, как возможно и отдельная специальность «верстальщик». Бизнесу так удобнее (посмотрите сколько вакансий на `fullstack`)
Плюс многие люди сами хотят развиваться дальше во фронтенд и не задерживаются надолго в «чистой» верстке.Zav Автор
05.01.2018 15:23+1Вёрстка/доправление простых макетов на потоке.
Покупается готовый готовый макет на любой площадке, доправляется таким верстальщиком, заполняется инфой и продается клиенту.
Есть компании которые делают это на потоке. Их достаточно.
Скучность и монотонность мы тут не обсуждаем.
Est. Budget — ну так опять же, это единоразовые небольшие работы. А реакт разработчики и прочие — постоянная работа над одним проектом. Фрилансер на небольших работах таких вполне может набирать до 3к$/месяц. Я лично знаю таких.
На хедхантере ищут в офис, да, поэтому и картина другая.
Wordpress — отличное решение для рядового сайта. Продаёт, например, друг леденцы ручной работы и просит вас сделать сайт. Взял вордпресс, взял тему, к вечеру сайт готов. Можно взять любую другую популярную CMS. На хостинг загрузил и готово (сравните с приложениями на ноде, хостингов «для обычных пользователей» до сих пор нет адекватных).
Вакансий фуллстек много, реальных фуллстеков кот наплакал. Говорю как реальный фуллстек :-) Приходится нанимать по старинке бекендеров/фронтендеров.
Ну т.е. фуллстек таки может уметь всё, но, например, на бекенде делает 10 единиц работы в час, а на фронте 2 единицы в час. Можно ему давать все задачи, а можно взять фронтендера с перекосом 10 на фронте, 2 на беке. И получить в сумме 20/час, а не 12.YemSalat
06.01.2018 05:20Мне в целом ваши мысли понятны, но немного сбивает с толку сама градация на джуниор/мидл/сениор.
Почему джуниору не начать сразу с распространенных практик в современной разработке (BEM, mobile-first, ..)?
Почему сениор ведет непосредственно к вордпрессу, а например не к углублению в ангуляр/реакт (компоненты, и т.п.)?
Довольно субъективная схема получилась в общем.Zav Автор
06.01.2018 13:331. Я в начале описал ожидания от верстальщика
2. Распространённые практики СЛОЖНЫ. Серьёзно. Вам может казаться что взял и готово, всё просто. Но это не так. Они требуют много знаний и понимания чего ты делаешь. Для их использования УЖЕ нужен опыт. Это точно не для начинающих.
3. Вордпресс это лишь пример. Ну и почему воддпресс я ответил прям в предыдущем сообщении.
4. Схема субъективна, это факт. Объективной схемы никто никогда не сделает :-)
dom1n1k
04.01.2018 14:52БЭМ на сегодня — стандарт де-факто (хотя выше и возражают), поэтому как минимум знакомым с ним должен быть абсолютно любой верстальщик.
Что касается реального применения, тут вопрос несколько более спорный, хотя лично я считаю это вариантом по умолчанию. То есть применять иные методологии можно, но для этого нужно иметь какие-то особые причины и/или специфику проекта; если таковых нет — не выделывайся, используй бэм :) Это правда хорошая практика.
ZaEzzz
04.01.2018 15:59+1Простите, где это сейчас БЭМ «стандарт де-факто»?
Я много фронтов повидал, но только в СНГ встречал «разработчиков на БЭМе» (именно в ковычках излишне фанатичных). Много зарубежных фронтов часто даже не слышали про БЭМ.
P.S. Очень интересное наблюдение: я не встречал зарубежных верстальщиков.Zav Автор
04.01.2018 16:05По опыту хочу сказать что очень не хватает квалифицированных верстальщиков даже в крупных популярных проектах.
Сами верстальщики таки встречаются, но тут зависит от специфики вашей работы.
На хабре много людей работают в высокотехнологичных компаниях, но есть много и гораздо более простых задач.ZaEzzz
04.01.2018 16:16+1Поправлю: часто можно наблюдать картину, что у команд крупных проектов не хватает квалификации в верстке.
Не хватает именно скилла в верстке у фронтов, а не хорошего верстальщика.
Верстальщик — это вакансия еще более специфичная чем дизайнер. Я часто вижу дизайнеров, которые умеют не только в фотошоп, но и в HTML+CSS. Так же часто вижу фронтов, которые не могут понять как отделить понятие верстки от их работы. Но только у нас в СНГ я встречаю верстальщиков, которые не могут писать код и дизайнеров, которые умеют исключительно рисовать.
Так что рекомендую вам начать изучать путь фронтендера — их очень не хватает, и не только у нас :)Zav Автор
04.01.2018 16:21Да, хорошее замечание, не хватает скила в верстке, абсолютно верно.
Хотя под словом «верстальщик» я подразумеваю не обязательно отдельного человека, но и того кто эти задачи выполняет в принципе.
Лично, я, если что, считаю себя software engineer'ом, а не верстальщиком. Это можно увидеть по другим моим статьям :-)ZaEzzz
04.01.2018 16:50Каюсь, не смотрел профиль.
Просто статью я понял немного своеобразно. Ведь для фронта логично испльзование IDE, а в статье это отдельный скилл верстальщика. При этом я не утверждаю, что фронту обязательно знать различные фреймворки — нужно знать язык и различные паттерны (вот интересная статья на эту тему habrahabr.ru/post/253297 ).Zav Автор
04.01.2018 17:00Да, так есть. Нужно понимать что ты делаешь, а не учить конкретный инструмент. Тем не менее ознакамливаться с тем что есть периодически надо.
RomanPokrovskij
04.01.2018 13:41+1Хороший результат — в смысле большая карта получилась. Но сильно искаженный масштаб. Именно верстку надо расскрывать подробней, а тут подробней расскрыто неспецифичное client-side программирование. И в смысле количества подробностей и даже геометрически в центр поставлена переферия.
Zav Автор
04.01.2018 13:49Поясните, пожалуйста, что имеется ввиду под «подробным» раскрытием вёрстки?
Мне видится это как набор множества связанных навыков, которые я и отразил в карте.
Прописывать карту тегов или чего-то такого… это не имеет смысла. Это справочная информация, которую не обязательно держать всегда в голове.
Может быть не совсем понял посыл.RomanPokrovskij
04.01.2018 15:30+1Вы описываете то что у вас в голове (даже с семантическими связями), и вдруг «в голове держать не надо».
Под раскрытием верстки понимаю именно что приемы верстки, т.е. перелопачивания работы дизайнеров в ХТМЛ. Чтобы их привести — надо их обдумать, сформулировать «чтобы не было просто карты тегов», предложить названия, сгруппировать, отсортировать по сложности — большая работа на самом деле (которая не проделана, хотя сразу этого можно и не понять смотря на масштабы карты).
Не задумывалось? Но вы названием статьи предложили меру которой хотите чтобы было оценено содержание.Zav Автор
04.01.2018 15:39Хм, ну умение выбрать нужный тег, скажем, я включил в блок «Семантика».
Умение разбивать сайт на блоки в «Блочную верстку».
Что бы оно ещё тянулось прям круто во «flexbox».
Далее мобильная и адаптив.
Я всё ещё не очень понимаю о каких техниках идёт речь.
RomanPokrovskij
04.01.2018 15:44+1Чтобы небыть голословным очевидными примерами приема верстки является понимание и умение пользоваться
1) «col» bootstrap'а ломающиеся от media-type.
2) умение стилизировать jquery plugin'ы
3) умение залезть в Chrome debugger и подгонять стили wyswig
и т.д
4) умение пользоваться тулзами которые загружают картинку и потом выдают названия шрифтов, цвета, гардиенты
5) умения задать вопрос дизайнеру (список вопросов которые можно задавать дизайнеру)
6) тоже программеру
список конечно не звучит — потому что необдумано и сформулировано плохо. и главное он не закончен, ведь система становится «приятной» когда она система, а не ее черновик.
я почему бурчу, сделайте эту работу — большое дело будет. интерес есть.Zav Автор
04.01.2018 15:51Хм, ну 1 я не счтиаю прям отдельным навыком. Это прям специфический момент с бутстрапом, который я опциональным ставил.
Стилизовать jquery плагины — ну как бы если с CSS и HTML разобрался, то… ну это же не отдельный навык. Почему именно jquery? Можно было бы записать как работу с чужим кодом, это да.
Chrome debugger, включено в джуниоре в инструментах разработчика.
Про тулзы: ну тут специфично. Я конечно назвал одну, CanIUse, но прочие — спорный вопрос на выбор. Шрифты, зачастую, есть в макетах или можно спросить у дизайнера и т.п.
Про вопросы — круто. Вот это можно было бы прям в отдельный пункт, но надо подумать как и куда.
aPiks
04.01.2018 14:25+2Вашу схему можно назвать «Кого бы мы хотели назвать верстальщиком, чтобы платить ему меньше.»
Верстальщик со знанием PHP и Wordpress уже не совсем верстальщик. Я бы даже сказал, что совсем уже не верстальщик. Аналогично и JS. Верстальщик не обязан знать JS. Верстка подразумевает цепочку действий от принятия макета до создания страницы для отображения в браузере. Статической страницы без какой-либо интерактивной части, максимум рекция на ховеры и анимация при появлении. Потом эту страницу берет Фронт-энд на пару с бэк-энд и цепляют туда логику, интерактив и тд.Zav Автор
04.01.2018 14:29Не совсем так. Более того, я убеждён что реально квалифицированный верстальщик в крупном проекте должен получать не меньше фронтендера.
PHP, JS и прочее на данной схеме я ставил на уровне «ознакомпления». Для того же вордпреса — есть разница в том что бы сделать свой шаблон и написать свой интерактивный модуль.
Про интерактив тоже не было речи. Как выше упоминал, процесс вижу при разработке с шаблонизаторами, в использовании моков (тестовых данных), либо в предоставлении условий (остается сделать только HTML, может с минимальными вставками {{переменных}}) со стороны фронтендера.
Evgeny42
04.01.2018 15:42+1Если уж выносить верстку в отдельную профессию, то сеньор верстки должен знать вообще все про способы оптимизации, про рендеринг в разных браузерах, их различия. А всякие методологии стоит учить еще будучи джуниором. И уж точно БЭМ не делает из человека сеньора.
Но вообще, это наверно дико скучно только верстать сайты. Наверно даже только фронт-эндом заниматься надоедает. Но тут уж каждый сам за себя решает.Zav Автор
04.01.2018 15:54Ну так то верстальщики и встречаются как отдельная профессия, либо в составе фронтенд-специалистов (которые не всегда умеют в вёрстку).
Само собой БЭМ не делает из человека серьора. Даже изучение всей карты не делает. Сеньор это способ мышления и умение решать и ставить задачи. В целом по градации было в начале стати.
Касательно того скучно или нет — лично мне нравится вёрстка. В крупных проектах довольно много интересных и не таких простых задач. Даже БЭМ сам по себе не даст все ответы. Простой вопрос: какой zIndex ставить для «блокирующей» области? А для попапа?
Zav Автор
04.01.2018 16:11Очень бы хотелось узнать за что ставится такое количество минусов.
Оставьте отзывы, пожалуйста, чем так плоха статья.
Спасибо.
derSmoll
04.01.2018 16:12+1Очень много спорного, можно дискутировать практически по каждому пункту, но начинание хорошее.
Из самого странного — в 2018-м году разносить по-отдельности CSS 1, CSS 2.1 и CSS 3, при чем CSS3 не раньше миддла, ват? Да и препроцессоры наверное уже можно ставить джунам по дефолту. Там же — есть stylus, но нет LESS, зачем вы его обижаете, он же клевый и популярнее стайлуса. А вот инструменты разработчиков браузера я бы расширил ниже — там очень много продвинутых инструментов, о которых даже не все сениоры знают и применяют.
В комментариях выше промелькнула мысль, что даже продвинутые фронтендеры довольно часто оказываются посредственными верстальщиками. Могу это только подтвердить — найти хорошего верстальщика нынче — крайне сложно, ведь все ударились в js.
У меня есть лайфхак — если хочется на собеседовании завалить сениора верстальщика/фронтендера (обычно не хочется, но мало ли), достаточно задать ему/ей три вопроса: о техниках оптимизации производительности, о доступности и о секьюрити клиентской части.
Ладно, скипнем секьюрность, но про accessibility я не увидел у вас пунктов.
Кстати, разметку AMP и ему подобные желательно верстакам уже знать хотя бы в общих чертах.
Zav Автор
04.01.2018 16:28Стандарты CSS наслаиваются друг на друга. В самом посте, в принципе, описано что включено в общих чертах. Ну т.е. изучая CSS 3 ты так или иначе изучишь CSS 2 и CSS 1.
Ну и так то по дефолту можно было бы вообще это всё джунам поставить, только так не бывает :-)
Про LESS было в тексте, например. Тут было важнее показать два лагеря — в одном CSS работает после переноса, а в другом его всегда надо переписывать.
Про инструменты разработчика — да, тут стоит расписать подробнее. Хотя их можно рассматривать в разделе «оптимизация» с ветками.
Про accessibility очень хорошее замечание. Многие забывают про доработки для людей с ограниченными возможностями. Стоит его добавить. Но, пожалуй, на уровень сеньёра, т.к., всё же, в большинстве случаев, это меньшая часть аудитории. Я старался покрывать схемой так, что бы минимум навыков давало максимум результата в плане покрытия.
Про AMP не писал, потому что, к своему стыду, первый раз слышу про эту технологию. Почитаю, спасибо.
stardust_kid
04.01.2018 18:19А что с секьюрностью-то? Это про защиту от XSS и CSRF, или я что-то упустил?
derSmoll
07.01.2018 00:17В том числе и про них. Также, есть нюансы с третьесторонними ресурсами, node_modules, индексацией не того, что нужно и все в таком духе. Интернет нынче крайне дырявый, и никто почему-то не чешется по этому поводу. Кстати, неплохая свежая статья на эту тему
kuftachev
04.01.2018 16:24+1Вы раскрываете свое виденье, но вопрос, сами берете таких джунов? Сколько их у вас и сколько им платите?
Что-то мне подсказывает, что если студия не работает над большими проектами, то не могут брать человека "который может внести правки", а возьмут того, кто умеет все от и до, пусть и слабо понимает какой-нибудь Git, особенно с учётом того, что маленькие проекты — это скорость разработки важнее возможности поддержки в будущем.
В общем, минусы за странности в статье, плюсы — за старания и поднятие темы.
Zav Автор
04.01.2018 16:33Лично у меня нет задач для джунов.
По оплате, если по данным скилам, то условно бы разделил как 20/50/100 тысяч для РФ.
Далеко не всем нужны супер навороченные адаптивные сайты.
Для многих рядовых задач может хватит навыков начинающего специалиста.
Я видел много студий, делающих лендинги на потоке за 10 000р/штука. Там такие начинающие и трудятся, делая по 3 штуки в день (без шуток), за тысяч 30 в месяц.
Это довольно утомительная и скучная работа, однако может быть вполне неплохой для наработки базового опыта.kuftachev
05.01.2018 14:21+1Посмотрел Ваш проект consulwar.ru. Впервые в жизни вижу, чтобы фотографии с отзывами использовались адекватно и реально вызывали доверие ))))
ipavlenko
04.01.2018 18:01+2На самом деле профессия «верстальщик» — это печальный удел.
Такое узкое самоназвание: «верстальщик», — должно определять человека на конвейерную работу — сверстал страницу, сверстал дргую — сдал проект, взял новый. Это рентабельно только если поток проектов — от 2 штук в месяц на 1 верстальщика.
Если верстальщик делает 2 проекта в месяц — значит он работает в коллективе, который сдаёт по 2 проекта в месяц. Это либо с первого раза сделанные как надо и не развивающиеся проекты (сомнительно), или сделал-забыл проекты с соответствующим отношением.
В реально живущем долго проекте места для чисто-верстальщика — нету, надо развиваться.
Прямой руководитель верстальщика будет от него требовать развития во front-части, пусть даже в ущерб его навыкам в вёрстке. Причина простая — проще ставить задачи на более высоком уровне.
А хороший-хороший фронт — должен любить по-верстать.
И в целом на проектах с нормальным жизненным циклом — дешевле дать хорошему-хорошему фронту сверстать проект. Это для него может оказаться отдыхом.Zav Автор
04.01.2018 18:42NDA не позволяет мне рассказать деталей, но я не согласен.
Верстальщик — соврешенно не значит конвеерную работу. Крупные проекты имеют сотни экранов, которые более менее регулярно обновляются и так далее. Зачастую не хватает человека, который бы координировал визуальные изменения по нескольким командам.
Тут можно спорить сколько угодно, но всегда есть две стороны монеты. Есть потоковая работа, о которой вы сказали, она вполне подходит для джунов/мидлов. На хай левеле есть много более интересных задач.
stardust_kid
04.01.2018 18:10+1За системный подход респект. Однако некоторые пункты устарели. Grunt и Gulp отправляются на пенсию. JQuery и PHP под большим вопросом. OOCSS только в комплекте с маркой хорошей кислоты.
Миддл должен мочь написать свою сетку на float и flexbox.
К БЭМ я бы добавил еще и другие паттерны архитектуры CSS — SMACSS, Atomic Design.
Также сеньор-помидор должен понимать и любить такие вещи как инлайновый контекст форматирования, как работает repaint и reflow в браузере. Еще пригодятся основы RESTfull и GraphQL архитектуры, чтобы хотя бы запросы мог писать.
Ну и благословенный React/Redux.Zav Автор
04.01.2018 18:39Спасибо.
Касательно устаревшести не соглашусь. Grunt и Gulp таки вполне используются. Вебпак настраивать ощутимо сложнее. Особенно как обучающий элемент некоей автоматизации вполне заходит.
Насчёт PHP — сейчас такая гора PHP проектов что игнорировать его, при всём желании, глупо. Мне самому не нравится PHP, если что, но считать что он умер (или умрёт ближайшие лет 10) не стоит.
Atomic Design таки уже привязывается к конкретным инструментам и выходит несколько за пределы чистой вёрстки. Но рассмотреть, хотя бы для понимания, подобные инструменты точно стоит.
Репейнт/рефлоу тут в разделе оптимизации отрисовки. Я намеренно не стал расписывать на много параметров, т.к. их всё равно надо изучать скопом.
Дёргать API с помощью jQuery умеют многие. Разбираться что там именно REST или что-то иное, на самом деле, не обязательно. Особенно если бек спроектирован грамотно и удобно. В случае ошибок легко поправить.staticlab
05.01.2018 02:29+1Вебпак настраивать ощутимо сложнее.
Но при этом в контексте Реакта или Ангуляра верстальщик скорее столкнётся именно с ним. И вот возникает вопрос: на старте проекта кто должен подготовить и настроить систему сборки? Если в Ангуляре там практически всё из коробки, то с Реактом может быть полный конструктор в зависимости от требований. Для стилей может использоваться и классические LESS/SASS, и современный CSS4/PostCSS, а может CSS Modules или Styled Components. Нужно настроить Autoprefixer, импорт и инлайн изображений (растровых и векторных), подготовить стили для иконок. И это всё ещё собственно до начала вёрстки компонентов!
Далее, попапы часто приходится выводить отдельно от основного компонента в корне иерархии DOM, чтобы им не мешали стили родительских контейнеров. Для этого может потребоваться довольно много кода. А это всякие селекты, календари и т.п.
Кажется, что "чистый" верстальщик без глубоких знаний современного фронтенда просто не потянет такую вёрстку. При этом очевидно, что в долгоиграющих проектах разумно делать разделение труда: core ui team в составе дизайнера и фронтендера с глубокими навыками вёрстки (верстальщика ли?) пилит общую библиотеку компонентов. Её затем используют при реализации бизнес-логики фронтендеры из других команд. При этом им серьёзных навыков в вёрстке уже не потребуется.
Проблема, как я уже сказал выше, в том, что в сложных компонентах вёрстка и внутренняя логика настолько тесно связаны, что просто так разделить обязанности на верстальщика и программиста не получится.
Zav Автор
05.01.2018 02:34Не одним SPA живём :-) В целом это уже означает что в проекте может не быть ни одного популярного фронтенд фреймворка.
stardust_kid
05.01.2018 02:52+1Ок. Могу принять вашу точку зрения. Но за "дергать api с помощью jQuery" бью падаванов по рукам. Есть же window.fetch и axios.
И webpack после трех лет знакомства мне кажется проще gulp. И, как выше заметили, при работе с React никуда от него не денетесь.
extempl
05.01.2018 13:13+1А зачем axios? Просто чтоб не использовать jQuery (читай не тянуть огромную библиотеку чтоб "дергать api с помощью jQuery")? А если его и так и так нужно изучать — какой смысл? Он тоже возвращает промисы. Fetch ок, конечно, но IE (как и старым андроидом) он таки не поддерживается. А полифилл тут — опять же, jQuery.
Конечно, лучше уметь использовать стандартные методы, меньше, быстрее,только труи т.д., но ведь речь про верстальщика.stardust_kid
06.01.2018 17:40+1Написание запросов средствами стандартного API намного более выразительно (eloquent), чем то же самое с помощью сторонних библиотек. Axios позволяет использовать Fetch API практически во всех броузерах.
sydorenko-vd
04.01.2018 18:50Сеньор верстальщик? Не слышал такого ранее.
SOLID
В верске?
Gitflow
Только для сеньора?
Zav Автор
04.01.2018 18:56Вот и я не слышал. Но чего бы не обозначить градации? Ведь не так всё очевидно.
SOLID вполне хорошо в проектирование компонентов ложится. Особенно если решите свой CSS фреймворк делать.
Gitflow полноценный ниже сеньёра не нужен. Процесс организует тимлид или СТО или ещё кто. Главное уметь коммитить, создавать ветки и так далее. Взаимодействовать с командой, в общем. А полноценно понимать что, зачем и как — уже ближе к руководящим позициям.
stardust_kid
05.01.2018 02:53Вот потому и в 90% проектов верстка ниже плинтуса. И столько команд предпочитают ходить по граблям.
vetero4eg
04.01.2018 20:13+1Офигеть, оказывается я не джун, а на 90% сеньор… только чет на работу не берут.
theaklair
04.01.2018 22:32Много сообщений о том, что верстальщик без знания фреймворка не нужен. В основном это пишут разработчики в крупных проектах. И, для них, это вполне так. Но есть ещё много студий делающих лендинги, различные шаблоны для вордпресов и других CMS. Это вполне себе хороший рынок и возможность зарабатывать. Есть довольно много совершенно небольших проектов, с гораздо меньшими требованиями, которые верстальщик способен закрыть на отлично.
Здесь нужно понимать, что:
1) Фреймворки — это по большей части именно SPA, и в мире Wordpress/CMS и лендингов SPA действительно чаще всего до сих пор невостребованы.
2) Если я правильно понял, то вы решаете разделить верстальщиков как таковых и фронтендеров (я лично рассматривал свою бытность верстальщиком как ступень к фронтенду, ибо писать логику приложения — это другой уровень), и вставляете в свою систему градаций верстальщиков еще и количество работ — но ведь как мы знаем количество очень часто может быть не равно качеству.
3) То «проектирование компонентов» о котором вы говорите, если я правильно понял то оно имеет прямое отношение к дизайн-системам, а потому и к дизайну как таковому, но почему-то в вашем списке нет пункта, в котором синьёр-помидор должен уметь в UI и гораздо важнее в UX.Zav Автор
04.01.2018 22:452. Не совсем так.
Во-первых это точно не «уровень к фронтенду». Я встречал крутейших фронтентеров не умеющих верстать (точнее с совсем базовыми навыками).
Фактически это разные навыки.
Про качество работ писал в самой статье и выше в комментариях. Можно изучить всё, и быть бесполезным, само собой.
Числа добавил исключительно для ориентации в пространстве.
3. UI/UX, всё же, это отдельные области. Посмотреть десяток макетов и выделить повторяющиеся элементы, грамотно их спроектировать (что бы не дублировались), довольно непросто. Это примерно как сделать свой bootstrap. Ну т.е. это вроде не то что бы сложно, но на рынке реально продуманных систем единицы. Иметь «свой бутстрап» в крупном проекте, с хорошей документацией и продуманой системой компонентов — одно удовольствие для дальнейшей разработки.theaklair
05.01.2018 00:11Чем же UI/UX «это отдельные области»? Не с UI ли вы работаете, верстая странички? Не UX ли лежит в основе всего того, что делают верстальщики и фронтендеры?
Кроме того, вы же не будете писать «свой бутстрап» не зная как и что должно работать?
Дизайнера тоже в сторонку поставим, пускай смотрит? :)Zav Автор
05.01.2018 00:27UI/UX это область дизайнера, по большей части.
В моем понимании задачей верстальщика является перевести картинку в рабочую штуку, но никак не давать советы по тому как эту картинку лучше сделать.
Само собой, с наработкой опыта глаз намётывается и навыки дизайнера в той или иной мере перенимаются.theaklair
05.01.2018 04:57Всё так, вот только UX это не про картинку, на самом деле.
Zav Автор
05.01.2018 13:22UX про сбор данных, AB тесты и прочее.
Однако релевантным опытом, что бы «попасть» сразу в хорошее обычно обладают дизайнеры.theaklair
05.01.2018 18:08Вижу вы не очень понимаете, о чем на самом деле UX.
Он не про данные, а про пользовательский опыт (что на самом деле и означает «User Experience»).
Сбор данных — он в свою очередь для аналитики. A/B — тоже для аналитики, которая уже в свою очередь может повлиять на предоставляемый пользователю UX.
Имхо, опять же, но ни о каком seniority в верстке не может идти речь, пока человек не отличает плохой UX от хорошего (о в целом не знает что такое UX).Zav Автор
05.01.2018 19:38Я понимаю более чем.
Имхо, опять же, но ни о каком seniority в верстке не может идти речь, пока человек не отличает плохой UX от хорошего (о в целом не знает что такое UX).
И почему же? :-)
Если предоставляется спека с подробной инфой что и как должно работать. Зачем этот навык верстальщику? :-) Ну т.е. он реально из другой плоскости прям.theaklair
06.01.2018 01:41В моем случае, то самое «seniority» о котором я говорю — это более широкое понятие, которое включает в себя и широту познания еще и смежных, взаимодополняющих вёрстку областей. Я снова приведу в пример тот же самый UX, которой у вас в списке не значится :)
«Seniority» — это не только о технических навыках, я вот о чем. Еще один пример — навык эстимирования\оценки задач. Но вы о нем кажется тоже не упоминаете.Zav Автор
06.01.2018 01:52Планирование — научиться оценивать сроки по картинке и определять последовательность работ.
Это касательно «не упоминается»
UX не идёт в смежные ни верстальщику, ни фронтендеру, ни, даже, фуллстеку. Это навык из СОВЕРШЕННО другой области, которая решается совсем иными путями и имеет абсолютно другой путь изучения.
extempl
05.01.2018 13:25+1UI про картинку. а UX это про то как это должно работать и как им будут пользоваться. А это, в свою очередь, должно ложиться в саму основу основ картинки. Всякие там эффекты и обратная связь добавляемые верстальщиком — это не особенно и UX.
theaklair
05.01.2018 18:11Чем же эффекты «не особенно UX»? Добавим плохой эффект в неправильное место — и получим плохой UX.
Например если пихать везде где нам вздумается анимации — это может вводить в заблуждение и отвлекать пользователя.extempl
05.01.2018 18:29+1Эм. Испортить можно что угодно в каком угодно месте. Но улучшить UX хорошим эффектом там где он (UX) плохой в самом дизайне — навряд ли исправит ситуацию.
Например если пихать везде где нам вздумается анимации — это может вводить в заблуждение и отвлекать пользователя.
Так а кто по вашему должен об этом думать? Верстальщик?
Хороший дизайн — это не только картинка. Это и описание поведения в том числе, чем и занимается UX дизайнер.
Zav Автор
05.01.2018 19:39Потому что какие эффекты и куда решает дизайнер, а не верстальщик.
theaklair
06.01.2018 01:45Senior не должен быть слепым орудием, он должен осознавать что он делает, и стараться сделать лучше, аргументированно объяснив причину того или иного решения, его плюсы и минусы.
Поэтому когда верстальщик видит, что предложенное решение дизайнера может навредить пользовательскому опыту — он должен, опять же, объяснить всем, как можно сделать лучше.Zav Автор
06.01.2018 01:54То ли у вас такие дизайнеры были не умеющие, то ли… ну не знаю даже.
Бывают случаи когда что-то можно подсказать дизайнеру (чисто с технической стороны), но мнить что у вас навыков больше чем у человека, который осознанную жизнь на этом специализируется… как то так себе.
Ol171
04.01.2018 22:45+1На схеме блок WordPress у сеньора расположен — удивился. Посмотрел в тексте, раньше должен быть)
BlackStar1991
04.01.2018 23:18Довольно занятная статейка, хотя и оценивание верстальщика по шкале выполненных работ… это сложно для моего понимания. Чистые верстальщики сейчас никому не нужны. без минимальных знаний JS. (Как минимум переделать готовый слайдер он должен уметь) + из статьи не понятно как оценить уровень, когда ты перешел из одной категории в другую. Я бы оценивал работы верстальщиков по кросбраузерности завершенной работы + Goggle PageSpeed. ПС Пишу как человек который сам проводил собеседование по найму Junior разрабтчика
Zav Автор
04.01.2018 23:26Оценивать по Google PageSpeed не корректно прям совсем, честно говоря. Он далеко не всегда показывает правду и надо к таким вещам относится с осторожностью.
Так же оценивать работу верстальщика по оптимизации (там много разных механик) — это такое себе.BlackStar1991
05.01.2018 00:09Это почему же Google PageSpeed вам не показатель? Если работа максимально кроссбраузерная, содержит нормы HTML 5 CSS3, валидатор на ней не краснеет + она не содержит ничего лишнего, (имеет минимальное количество запросов к сторонним сервисам и они выполняются именно тогда когда надо). И при этом PageSpeed тесты показывают >90%. Как по мне это показатель
Zav Автор
05.01.2018 00:25Это зависит от специфики вашей работы.
Может быть для вас это действительно идеальный показатель, тут я был не прав, выходит.
bro-dev
05.01.2018 02:33+1Потому что будет ругаться за свои же компоненты карту шрифты метрику. А советы типо с начало верстку, а шрифты стили и скрипты потом подходят тока для коротких страниц, а других всё видно как прыгает.
yurch-html
07.01.2018 01:08Умение оптимизировать под гугл спид это полезный навык.
А можно подробнее про запросы, какие именно запросы, когда выполняются?
yurch-html
08.01.2018 01:11В статье очень недооценен джуниор. Описание больше подходит для трейни.
И получается что джуны начинают себя мнить мидлами.
SergDevGuy
04.01.2018 23:26Добрый вечер.
zav Алексанр (автор поста), мне очень понравился ваш пост, спасибо.
Если у тебя будет желание учесть все комментарии и дополнить/изменить таблицу/пост, добавив всё новое и переосмысленное в схему и в дополнительный абзац после статьи, это будет превосходно, потому что схема получилась годной и если её можно ещё улучшить учитывая отзывы других опытных людей… это будет Вау. Пишу как человек, который повидал много схем и уроков.Zav Автор
04.01.2018 23:27Обязательно дополню и расширю, как только будет полноценное видение что именно добавлять (кроме того, что я отмечал в комментариях).
Спасибо.
Rocky_Balboa
05.01.2018 13:23+2ну, проблема нехватки специалистов, она в-принципе в направлении ИТ. Не то, чтобы именно верстальщиков мало. Многим просто верстка кажется не интересной. И потом, в образовательных учреждениях никогда не будут преподавать верстку, и рассказывать, как это классно. + многие ИТшники пренебрежительно относятся к верстальщикам, поэтому мало, кто хочет этим заниматься.
Zav Автор
05.01.2018 14:34Планирую составить аналогичные карты для frontend и backend разработчиков. Потом объединить все карты в fullstack.
Если, вдруг, кто желает помочь составить адекватную карту и поделиться своим видением — присоединяйтесь к телеграмм каналу https://t.me/zav_programming
vconst
06.01.2018 10:14+1Автору вопрос.
Вы в комментариях очень много пишете о том, что фронтенд — плохой верстальщик. А можно как-то конкретнее это объяснить? Мне всегда казалось, что фронтенд — это очередная и логичная ступень развития верстальщика, сначала делается сайт, потом на него накладывается логика и динамика. А фронтенд по определению должен хорошо верстать. Мне понятно, что программирование не всем дано и это определённый склад мышления, который есть не у каждого. Но вёрстка то — чисто механическая работа, по определённым правилам расставить блоки с текстом и изображениями на странице. Тем более, что в вашей картинке сначала идёт одна статика для десктопов.
Что в верстке может вызвать такое затруднение, что программист точно не справится? Не сумеет правильно расставить теги? Выберет не те? Не разведет блоки по разным сторонам макета или не сможет построить сетку? Что именно может вызывать и вызывает проблемы у программистов в верстке? Теги, правильный выбор селекторов или набор свойств?
Тогда уж — а что именно вызывает проблемы у верстальщика с небольшим опытом в верстке сайтов? Если судить по вашим словам — эти проблемы должны быть аналогичны тем, что возникают у программистов. Ведь не может быть, что одно только знание ехнологии — продвигает специалиста вперёд. Есть же и особенности применения технологий, одни правильные, другие нет. И разве этому можно научиться только по книжкам, в которых, например, рассказывается про свойства css?
У меня не много опыта в верстке и программировании, и очень интересно, не что именно надо изучать, а как. Потому что подробных карт — множество, реально дофига. Те же самые курсы html academy — можно открыть список и все примерно совпадет, за исключением того, что они не углубляются в более продвинутые технологии на курсах — для этого у них есть интенсивы.Zav Автор
06.01.2018 14:04Я не писал что фронтенд — плохой верстальщик. Я писал что, зачастую, человек уходя во фронтенд остается на уровне джун-мидл. Это разные навыки, требующие разного мышления, как вы и написали.
С одной стороны вёрстка — чисто механическая работа по определённым правилам. С другой стороны — 95% программирования это чисто механическая работа по определённым правилам. Для большинства уже есть готовые алгоритмы. Вам даже сортировки знать не надо (для большинства рядовых задач), ведь есть .sort().
Хорошего верстальщика отличает именно то, что у него в голове уже есть информация об актуальных браузерах, ограничениях, десятке разрешений экрана, версии для слабовидящих и так далее. Ещё очень важна разница во времени в дальнейшей поддержке. Ну т.е. хороший верстальщик сделает за день, фронтендер со средней версткой сделает за два и ещё 3 будет доправлять баги.
Ну т.е. вопрос, скорее, не в том что вызывает такое затруднение, а затрачиваемое время. Многие программисты не интересуются ни БЭМом, ни OOCSS, ни другими техниками. Они им не интересны. «Это всего лишь вёрстка» — говорят они. А потом проект невозможно поддерживать.
Говорить на английском — простая, чисто механическая задача. Заучить порядка 5000 (для начинающего 500) слов, разобраться в правилах… да и всё. Но почему то даже если человек обладает словарным запасом, понимает синтаксис и так далее, для полноценного выхода на уровень надо «наговорить» хотя бы часов 500. Это просто навык, который нарабатывается.
Вёрстка тоже просто навык, который нарабатывается. И программирование. И дизайн, что бы вам не говорили.
Я сам вёл некоторые курсы и изучал существующие.
То что сейчас есть на рынке — оно, на самом деле, не годится для того уровня, который заявляется. Это сраный маркетинг.
Что бы выйти на нормальный уровень во фронтенеде нужно затратить порядка полугода фуллтайм. Хотя бы 1000 часов суммарно. При этом если заниматься по «паре часов», то итог смело можно умножать на 2-3. Т.е. при 4 часах в неделю, нужно лет 5.
Те, кто реально выходит с этих курсов и потом устраиваются, обычно, самомотивированы и помимо курсов тратят на учебу всё своё свободное время.
У меня было желание сделать курсы на базе существующих платформ (писал письма разным кампаниям). Предлагал полноценный длительный курс. Оказалось всё просто. Его не продать :-) Ну это и вполне очевидно. Многие тешат себя надеждой, что вот сейчас за пару месяцев по выходным пройду супер-курс и начну зарабатывать 100 000. Так НЕ БЫВАЕТ.
Вообще есть желание по данной теме отдельный пост сделать, но либо как-нибудь потом, либо никогда :-)
yurch-html
06.01.2018 16:25+1Автор молодец. «в верстке есть очень много левых людей», которые не брезгуют высказать свое мнение, которое оправдывает их самих, и в свою очередь, сбивает с толку менее опытных.
У меня на работе фронты отдельно и верстаки отдельно.
Фронды действительно в верстке уровня джун, и за частую так и бывает.
Хотя я бы не делил уровни по количеству работ. Для меня синьйор, это отличные навыки с сложными цсс свойствами. 3д анимации?svg, кенвас, сложные гладиенты, DRY в лучшем его виде и js/
x07
06.01.2018 17:09У меня на работе фронты отдельно и верстаки отдельно.
Как у вас организован процесс совместной разработки при таком разделении?
… сложными цсс свойствами
Это что за свойства такие?yurch-html
07.01.2018 00:46анимейт, трансформ, клип, маски, градиенты
x07
07.01.2018 13:51А процесс совместной работы как организован?
yurch-html
07.01.2018 16:21с верстальщика оформление, с фронта логика.
x07
08.01.2018 13:17Кто потом это все совмещает и правит ошибки? Время сколько на это уходит? Насколько это эффективно?
yurch-html
08.01.2018 18:22Компоненты в фреймворке создавать может верстальщик, править баги верстки тоже верстальщик.
Это эффективней чем один фронт с плохим знанием верстки, но не эффективнее чем один фронт с хорошим знанием верстки.
Zav Автор
06.01.2018 18:15Спасибо.
Про количество работ я уже давал комментарии тут — это просто ориентир для тех, кто хочет пройти путь, не более.
Imbecile
Senior в современном мире и без angular/react/vue? Очень странно.
Zav Автор
Для верстальщика достаточно понимания того, как работает шаблонизатор в представленных фреймворках. Если бы это бы frontend-разработчик, то, как минимум, знать и понимать их бы требовалось.
Imbecile
Ну не знаю. Всё-таки компонентная парадигма, она требует чуть более глубокого изучения вопроса и конкретного фреймворка/библиотеки. И ладно бы это я, фулстек разработчик, так думал. Но нет, вот недавно встречался с бывшей сотрудницей-верстальщицей. На новом месте активное изучение React именно в контексте вёрстки. Никакой разработкой с её стороны и не пахнет.
Да и jQuery у вас на схеме упомянут, а у него связей с вёрсткой на порядок меньше, чем у упомянутых мною фреймворков и библиотек.
P.S. За статью, в любом случае, спасибо. Как минимум заставляет задуматься над вопросом структуирования необходимых навыков для определённой области разработки.
Zav Автор
Схему можно бесконечно долго расширять.
Я постарался выделить тот минимум, который является базой, и без которого прям очень сложно.
Можно изучать реакт, и прийти в проект где этого реакта нет. Но да, изучение ЛЮБОГО фреймворка улучшит понимание и процесс разработки. Я намеренно выделил «Шаблонизаторы» в отдельный пункт. Сюда можно было бы добавить и реакт, и ангуляр, и любые другие фреймворки со своей структурой.
Тем не менее уметь делать шаблоны и разрабатывать на фреймворке требует совершенно разных навыков и разного понимания.
x07
У реакта нет шаблонизатора. Верстальщик должен понимать сам реакт, что бы написать код компонента.
Для ангуляра, вуя и всех современных фреймворков отдельно верстать шаблоны — это лишний геморой.
Как у вас выстроен этот процесс? Верстальщик тратит 30 часов на один компонент, а потом фронтендер берет его код, тратит еще 30 часов, разбивает его до неузноваемости навешивая туда логику? Как потом верстальщик исправляет косяки верстки в итоговом результате, лезет в код приложения и навешивает заплатки в css?
Zav Автор
Ну таки JSX можно назвать шаблонизатором в каком-то виде.
Даже читые ${} в js можно назвать шаблонизированием, в целом.
Ангуляр, вуй и прочие вполне (иногда) имеют отдельные обособленные HTML участки. Да, с дополнительной логикой типа {#each} или дополнительными аттрибутами тегов, или вообще с собственными тегами-директивами. При понимании того, как работают блоки в целом и начилии базового понимания JS, да и уж с минимальным изучением конкретного фреймворка, у верстальщика не составляет проблем сразу делать как надо.
Если вопрос конкретно про наш проект, то у нас blaze. Можно сказать что Handlebars. Он достаточно прост. Обработчики можно вешать как извне так и добавляя onClick={{someAction}} или подобное. При наличии прочих навыков изучается за день.
x07
Не думаю, что у тех кто понимает что такое JSX, повернется язык назвать это шаблонизатором в каком-то виде.
так это и называется шаблонные строки
Так в итоге это верстальщик или уже фронтендер? Зачем пускать туда человека, который имеет базовые знания и может делать только какую-то малую часть(возможно даже криво и неэффективно), в итоге же может получится так, что опытному разработчику придется все переделывать за верстальщиком с нуля. Двойная работа на лицо.
У вас в проекте, если меняется логика в приложении, или набор данных который надо визулизировать становится другим, кто правит шаблон, верстальщик или фронтендер, или у вас нет фронтендеров и все делает сеньор верстальщик? Не получается ли у так, что верстальщик говорит что его код работает, а после добавления логики все сломалось и это не его косяк? Как вы определяете кого наказывать, а кого поощрять?
Zav Автор
Верстальщик :-)
Я не разрабатывал приложения конкретно на реакте, могу сказать за ангуляр. Хороший верстальщик может (как бы не было странно) хорошо сверстать. Далеко не каждый фронтендер умеет хорошо верстать — это факт. Если предоставляются данные в шаблон, то верстальщик вполне сможет их вставить как надо, используя простейшую логику.
Полноценная проработка компонентов требует иных компетенций, нежели качественная вёрстка.
У нас сейчас фуллстеки все.
Честно говоря слабо представляю как может сломаться вёрстка после добавления логики. Если она, таки, ломается, то это явно проблема фронтендера, в данном контекте.
Вёрстка же может делаться (и делается, зачастую) на моках, а не на реальных данных.
Окей, убедили, в схему нужно добавить умение создавать моки под задачи.
Я обязательно напишу отдельную статью про кучу ошибок которые совершил, как руководитель, за последние 3 года разработки своего проекта и чему научился. :-)
x07
Никак не могу понять, как идет разделение на верстальщика для фреймворка и разработчика на фреймворке. Интересно было бы почитать про весь процесс такой разработки на каком-нибудь примере. Я видел вакансии по типу верстальщик реакт, ангуляр но никак не мог понять в чем выгода такого разделения?
Сеньор верстальщик сверстал макет по мокам и протестил его, но он не учел, что реальные данные там окажутся куда больше чем в моках, и, например, появился скролл, в результате чего поехала верстка. Выявили косяки в других браузерах, на других разрешениях(как бы не тестил сеньор верстальщик — это неизбежно).
Это кстати справедливо не только для фонт фреймворков, но так же эта проблема актуальна для различных CMS и бекенд фреймворков
Zav Автор
Выгода от разделения в том, что гораздо проще нанять крутого верстальщика и крутого фронтендера, чем крутого фуллстека (обычно отдельные навыки слабее чем у пары узких спецов).
Ну тут… не учел… а ты учти :-) Важна регулярность таких ошибок. Вообще, ошибки — это нормально, важно как они разрешаются. Ну т.е. вот вылезет проблема у верстальщика что он не учел что-то — поправит и учтёт в следующей работе. Процесс обучения важен, как-никак. Ну и при взаимодействии с разработчиками научится лучше понимать ваш движок.
ByRon
К примеру вёрстка разломается когда её в Ангулар разобьют по компонентам т.к. вставляться будет уже через дополнительный тег <xxx-component></xxx-component> — как минимум нужно установить каким этот будет блок, блок, инлайн, флекс и т.д. + наследование css может заблудиться т.д.
Так верстальщик Ангулар я понять вполне могу, когда после простой вёрстки — фронтендер разбивал её на компоненты и всё ползло в разные стороны.
x07
Senior — верстальщик? Всегда думал что верстальщик это зародыш фронтенд разработчика. А тут вон как оказывается!
Zav Автор
В этом и прикол.
Зачастую фронтенд-разработчики останавливаются на джун-мидл уровне верстальщика, считая что там «нечего делать».
psy06
Всегда думал что верстальщик это работник типографии, а оно вона как…
Zav Автор
Там тоже верстальщик, но другой :-)
Zav Автор
del, добавил не туда