JavaScript во время верстки проектов

Я 20 лет занимаюсь web-разработкой. Отшумели войны фреймворков на бэк- и фронтэнде. Тройка лидеров не меняется годами. Всё, бляха-муха, должно быть уже стандартизировано, автоматизировано и выяснено. Но некоторые темы все ещё вызывают жаркие споры.

Итак, первая тема, о которой разработчики готовы спорить до хрипоты:

🦖 Когда-то на земле жили динозавры. И существовала целая специальная профессия «верстальщик». Впрочем, судя по курсам и вакансиям, динозавры встречаются и по сей день. Задача верстальщика была перевести картинки от дизайнера в пригодный для браузера вид: html+css.

Шло время, фронтенд рос и усложнялся. Появились сборщики проектов, бандлы, требования к анимации, интерактиву и даже целому пласту бизнес-логики, который ожидается «из коробки». Например, от чего бы верстальщику сразу не сделать кастомные выпадающие списки, вроде Select2? Или показатель Google Page Speed в зеленой зоне? А что бы и нет?!

👻 Ничего сакрального именно в этих требованиях нет. Просто таких ожиданий с каждым годом становилось всё больше и больше. Верстка в «чистом html», без учета компонентного подхода уже мало кого устраивала. Часто ее приходилось выбрасывать и переделывать уже при «натягивании» верстки именно из-за того, что не были учтены какие-то Javascript-нюансы.

😵💫 Современный Frontend, кстати, часто сложнее Backend. Не догма, но так бывает, часто. Это уже не json-ны из левого кармана в правый перекладывать, тут нужно про всякие SharedWorkers и ServiceWorkers знать. Ну и добро пожаловать в чудесный асинхронный мир (о котором многие backend-программисты даже не догадываются).

В разных компаниях и командах ожидания от верстальщика разные. Где-то все еще простительно получить от него сырой html. А где-то, как у нас, требуются почти готовые vue/react-компоненты, к которым остается прикрутить бизнес-логику. Споры и холивары крутятся вокруг того, какой объем JS/Typescript-кода должен выдать верстальщик «по умолчанию».

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

 —Переводи.
 — Зачем ты это переводишь, я это понял…
 — Ну че ты замолчал? Почему не переводишь? Это я не понял!
 — Да это я понял, молчи.
 — Что молчишь! Ничего ж непонятно?

💩 В мире стремительно побеждающих No-Code/Low-Code-систем (привет, Тильда!) споры среди программистов по этому вопросу выглядят архаично. Но они есть. А финальной точки тут до сих пор не поставлено.

Что делать руководителю проекта, если на проекте подобные споры регулярны и мешают работать?

• Во-первых, хорошо помогает стабильная команда, которая притерлась друг к другу. В которой уже сформированы ожидания и эти «детские болячки» прошли. Именно поэтому нанять сработавшуюся команду на старте выгоднее, чем собирать каждый раз новую, под конкретный проект.
  
• Во-вторых, нужно убрать демократию. Есть у вас технический лидер? Прекрасно. Вот как он сказал — пусть так и будет. У него, в конце концов, должность и работа такая.
  
• Если команда новая, люди не притерлись, а техдир слаб (в морально-волевом плане) и не очень-то авторитет — вы в беде. Придется пройти все стадии по Такману. Хвалить тех, кто производит результат (а не споры). Идти мелкими итерациями. Проводить регулярные ретроспективы. И формировать право обычая.

Успехов!

Больше полезного — в блоге Владимира Завертайлова в Telegram.