Комментарии 9
Не очень понятно как в SPA получается выделять задачи чисто на вёрстку. У меня происходит как-то так:
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 не нужно тащить.
Короче вопрос: как у вас получается шаг вёрстки выделить и делать отдельно от остального?
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), а также не сильно усердствовать с агрессивным выделением компонентов — то результат "нарезки" остаётся вполне понятен верстальщику, и способен им редактироваться.
А что мешает тому самому «приболевшему верстальщику» верстать на больничном? Или, хотя бы, консультировать коллегу? Я серьезно не понимаю, объясните пожалуйста. Или под «болезнью» имеется ввиду что-то вида срочной операции под общим наркозом?
Просто привык всю жизнь работать на фрилансе, а там другие законы, и заказчику обычно все равно, кто там и чем болеет. Программирование это же не вагоны разгружать.
Просто привык всю жизнь работать на фрилансе, а там другие законы, и заказчику обычно все равно, кто там и чем болеет. Программирование это же не вагоны разгружать.
Все таки верстка уже давно перестала быть вещью в себе. Сейчас можно быть прекрасным верстальщиком и не менее сеньорным фронтендером. Это не две такие области, которые перетягивают внимание друг у друга и конфликтуют, как в случае с фулл-стеками, где у тебя обязательно будет проседать один из твоих «side». Даже некоторые дизайнеры уже постигают верстку на таком уровне, что не стыдно такое в продакшен тащить. Более того, верстка и javascript настолько гармонично сплетены между собой, что сложно представить себе, что кто-то не может перетекать из одного в другое. Необходимо прилагать усилия, чтобы этого не происходило.
Поэтому на месте верстальщиков я все-таки побоялся бы оставаться настолько нишевым специалистом. Да, в конкретно вашей компании чистые верстальщики ценятся, но в целом по рынку такие люди проиграют конкуренцию по большинству пунктов даже средним фронтендерам. Взяв любой css-«фреймворк», ты все равно сталкиваешься с каким-то js кодом. Bootstrap, material design, ant design — ты не достигнешь 100% планки понимания этих библиотек, если не ковырялся в их js api.
Верстка это не те же базы данных, где, достаточно углубившись в область, ты утрешь нос всем бэкендерам, которые тоже думают, что знают базу данных. Потому что в верстке углубляться-то не особо есть куда. Верстка имеет достаточно низкий порог входа и достаточно невысокое плато кривой, на которой ты можешь решить практически любую задачу на хорошем уровне. Человек, который достиг этого плато и не желает расти куда-то в параллель, просто останавливается в развитии и это происходит очень быстро. Году эдак на втором, максимум третьем. Имеет ли высокую ценность такой специалист на рынке? Сомневаюсь.
Единственное оправдание наличию таких специалистов в команде может быть лишь в одном — они, возможно, дешевле, чем хороший фронтендер с экспертным уровнем вверстке. Но разве кто-то добровольно захочет надолго оставаться дешевым специалистом. Джуниоры перерастают в миддлов. Верстальщики перерастают во фронтендеров. Если вы удерживаете их на этом уровне, рассказывая о том, что они на самом деле поступают верно — вы им врете.
Поэтому на месте верстальщиков я все-таки побоялся бы оставаться настолько нишевым специалистом. Да, в конкретно вашей компании чистые верстальщики ценятся, но в целом по рынку такие люди проиграют конкуренцию по большинству пунктов даже средним фронтендерам. Взяв любой css-«фреймворк», ты все равно сталкиваешься с каким-то js кодом. Bootstrap, material design, ant design — ты не достигнешь 100% планки понимания этих библиотек, если не ковырялся в их js api.
Верстка это не те же базы данных, где, достаточно углубившись в область, ты утрешь нос всем бэкендерам, которые тоже думают, что знают базу данных. Потому что в верстке углубляться-то не особо есть куда. Верстка имеет достаточно низкий порог входа и достаточно невысокое плато кривой, на которой ты можешь решить практически любую задачу на хорошем уровне. Человек, который достиг этого плато и не желает расти куда-то в параллель, просто останавливается в развитии и это происходит очень быстро. Году эдак на втором, максимум третьем. Имеет ли высокую ценность такой специалист на рынке? Сомневаюсь.
Единственное оправдание наличию таких специалистов в команде может быть лишь в одном — они, возможно, дешевле, чем хороший фронтендер с экспертным уровнем вверстке. Но разве кто-то добровольно захочет надолго оставаться дешевым специалистом. Джуниоры перерастают в миддлов. Верстальщики перерастают во фронтендеров. Если вы удерживаете их на этом уровне, рассказывая о том, что они на самом деле поступают верно — вы им врете.
Верстальщики перерастают во фронтендеров. Если вы удерживаете их на этом уровне, рассказывая о том, что они на самом деле поступают верно — вы им врете.
У нас есть есть и возможности, и работающие процессы перехода верстальщиков во фронтенд- разработку и не только. И истории такие в компании есть. Есть кейсы перехода с верстки на JS, есть кейс перехода в разработку на dart (бизнес-логику мы пишем на dart), есть случай перехода верстальщика на роль выделенного scrum-мастера.
Врать человеку в плоской организации, где вся разработка у всех инженеров компании на виду, где прозрачные роли и задачи каждого в команде, где есть понятные векторы развития человека в команде верстки и в rnd в целом, невозможно.
Потому что в верстке углубляться-то не особо есть куда. Верстка имеет достаточно низкий порог входа и достаточно невысокое плато кривой, на которой ты можешь решить практически любую задачу на хорошем уровне.
На спор пройдёте собеседование на вакансию верстальщика у нас? :)
На спор пройдёте собеседование на вакансию верстальщика у нас? :)
Хотите решение win-win?
Могу попробовать закрыть пару реальных тасок, которые сейчас у вас стоят перед верстальщиками, а вы оплатите мое время по моей текущей ставке, включая время на вход в проект, изучение документации и разработку решения, которое я могу обсудить с командой (абсолютно равные рабочие условия, которые вы ставите перед остальными сотрудниками). Вы в плюсе, я в плюсе, у всех будет мотивация закрыть задачу успешно, а не доказать что-то любыми путями. Ибо если вы будете ставить себе задачей любой ценой не дать мне выполнить работу, вы ее без проблем добьетесь — саботирование работы одного индивидуалиста целой компанией и группой людей по предварительному сговору не rocket-science.
Может быть у вас появиться еще один фронтендер на подхвате, которого можно будет звать, когда прижимает по времени остальных, с практически нулевыми затратами на рекрутинг.
Собеседование для собеседуемого, который не приглянулся собеседующему — это неравная схватка, уж мы-то понимаем. :) Плюс еще и контрпродуктивная, в отличие от моего варианта, в котором есть реальная мотивация для обеих сторон.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 верстальщиков на 30 команд. Вы рехнулись?