Comments 9
1. дизайнеру дают задачу, они рисует скрин, все смотрят, уточняют, готово
2. отдаем фронту
3. фронт прикидывает как разбить скрин на компоненты
4. создает компоненты, связывает между собой
5. параллельно к кажому компоненту делает к нему .scss, импортит его, и сразу накидывает классы и стили
6. поправить стили, поправить логику, разбить/слить компоненты, и далее по кругу.
Если я выделю шаг #5, то будет дико сложный процесс — фронт не сможет увидеть ничего, пока к нему не придет верстак и поможет. Причём не просто поможет, а через pull-request-ы и code review еще.
И это учитывая что вёрстка — 10% работы. Потому что все нетривиальное — уже в компонентах, а всякое простое — flexbox-ы и прочие position: absolute — вообще не проблема выучить. Ну, если уж в TypeScript разобрался — чего там тебе эти FlexBox-ы.
Это не говоря уже о всяких таймлайнах на canvas-е, где вообще CSS нет. И о том, что всё сложное в вебе делается через «ну ок, CSS снова не смог, берем JS и position: fixed». Ну и что компоненты разделять надо сразу с учётом верстки. И что всякие "::after", и много еще какой дичи из мира CSS, в SPA не нужно тащить.
Короче вопрос: как у вас получается шаг вёрстки выделить и делать отдельно от остального?
Во-первых, у нас есть ui-kit, то есть библиотека компонентов, за которую отвечают вышеописанные ребята. И часто реализация задачи выглядит так: мок уже собран из компонентов, мы пишем логику, используя эти компоненты и минимально необходимую вёрстку, а затем отдаём на "доводку".
Во-вторых, так как компоненты во многом уже готовы к использованию, многие задачи "автоматически" оказываются правильно сверстаны и крафтер (верстальщик) только ревьюит и вносит косметические правки.
Всё просто же: сначала верстальщик делает статическую страницу, потом фронтендер оживляет её и "нарезает" на компоненты.
Если при этом использовать фреймворки либо библиотеки с нормальной разметкой (т.е. не React и уж точно не mol), а также не сильно усердствовать с агрессивным выделением компонентов — то результат "нарезки" остаётся вполне понятен верстальщику, и способен им редактироваться.
Просто привык всю жизнь работать на фрилансе, а там другие законы, и заказчику обычно все равно, кто там и чем болеет. Программирование это же не вагоны разгружать.
Поэтому на месте верстальщиков я все-таки побоялся бы оставаться настолько нишевым специалистом. Да, в конкретно вашей компании чистые верстальщики ценятся, но в целом по рынку такие люди проиграют конкуренцию по большинству пунктов даже средним фронтендерам. Взяв любой css-«фреймворк», ты все равно сталкиваешься с каким-то js кодом. Bootstrap, material design, ant design — ты не достигнешь 100% планки понимания этих библиотек, если не ковырялся в их js api.
Верстка это не те же базы данных, где, достаточно углубившись в область, ты утрешь нос всем бэкендерам, которые тоже думают, что знают базу данных. Потому что в верстке углубляться-то не особо есть куда. Верстка имеет достаточно низкий порог входа и достаточно невысокое плато кривой, на которой ты можешь решить практически любую задачу на хорошем уровне. Человек, который достиг этого плато и не желает расти куда-то в параллель, просто останавливается в развитии и это происходит очень быстро. Году эдак на втором, максимум третьем. Имеет ли высокую ценность такой специалист на рынке? Сомневаюсь.
Единственное оправдание наличию таких специалистов в команде может быть лишь в одном — они, возможно, дешевле, чем хороший фронтендер с экспертным уровнем вверстке. Но разве кто-то добровольно захочет надолго оставаться дешевым специалистом. Джуниоры перерастают в миддлов. Верстальщики перерастают во фронтендеров. Если вы удерживаете их на этом уровне, рассказывая о том, что они на самом деле поступают верно — вы им врете.
Верстальщики перерастают во фронтендеров. Если вы удерживаете их на этом уровне, рассказывая о том, что они на самом деле поступают верно — вы им врете.
У нас есть есть и возможности, и работающие процессы перехода верстальщиков во фронтенд- разработку и не только. И истории такие в компании есть. Есть кейсы перехода с верстки на JS, есть кейс перехода в разработку на dart (бизнес-логику мы пишем на dart), есть случай перехода верстальщика на роль выделенного scrum-мастера.
Врать человеку в плоской организации, где вся разработка у всех инженеров компании на виду, где прозрачные роли и задачи каждого в команде, где есть понятные векторы развития человека в команде верстки и в rnd в целом, невозможно.
Потому что в верстке углубляться-то не особо есть куда. Верстка имеет достаточно низкий порог входа и достаточно невысокое плато кривой, на которой ты можешь решить практически любую задачу на хорошем уровне.
На спор пройдёте собеседование на вакансию верстальщика у нас? :)
На спор пройдёте собеседование на вакансию верстальщика у нас? :)
Хотите решение win-win?
Могу попробовать закрыть пару реальных тасок, которые сейчас у вас стоят перед верстальщиками, а вы оплатите мое время по моей текущей ставке, включая время на вход в проект, изучение документации и разработку решения, которое я могу обсудить с командой (абсолютно равные рабочие условия, которые вы ставите перед остальными сотрудниками). Вы в плюсе, я в плюсе, у всех будет мотивация закрыть задачу успешно, а не доказать что-то любыми путями. Ибо если вы будете ставить себе задачей любой ценой не дать мне выполнить работу, вы ее без проблем добьетесь — саботирование работы одного индивидуалиста целой компанией и группой людей по предварительному сговору не rocket-science.
Может быть у вас появиться еще один фронтендер на подхвате, которого можно будет звать, когда прижимает по времени остальных, с практически нулевыми затратами на рекрутинг.
Собеседование для собеседуемого, который не приглянулся собеседующему — это неравная схватка, уж мы-то понимаем. :) Плюс еще и контрпродуктивная, в отличие от моего варианта, в котором есть реальная мотивация для обеих сторон.
10 верстальщиков на 30 команд. Вы рехнулись?