За последние несколько месяцев не проходило и недели, чтобы я не слышал о другой компании, чей фронтенд-проект опаздывает, ломается, выходит за рамки бюджета или просто гротескно неэффективен. Менеджеры все еще не хотят мириться с кошмаром фронтенд-разработки в 2016 году?
Во-первых, фон
У нас небольшая консультация по внешнему интерфейсу, и помимо создания продуктов с нуля, нас зовут помочь компаниям решить проблемы с их кодом Angular или React. В последнее время часть «проблем» росла и росла.
У каждой компании, которую мы встречаем, есть проблемы с производительностью, неуправляемый код, пропущенные вехи и разработчики, которые увольняются направо и налево. Тесты и КИ? Хе. Половина из них никогда не слышали об инструментах сборки. Даже среди тех немногих, кто, кажется, выпускает код, менеджеры разработчиков признают, что единственный способ выполнить поставленные руководством задачи — удалить огромные части запланированных функций.
Что, черт возьми, происходит?
Поэтому мы начали задавать вопросы и осматриваться. Что удивительно? У крупных компаний все хорошо. У них есть четкое разделение между командами, и наличие обученной команды, посвященной внешнему интерфейсу, является нормой. Это небольшие «гибкие» компании с 1–3 разработчиками интерфейса, которые продолжают с треском терпеть неудачу.
Эти небольшие команды обычно состоят из бывших разработчиков серверов, только что окончивших школу младших школьников и руководителя группы, у которого «30% свободного времени и который действительно хочет писать код». В большинстве случаев они «учились на ходу», и у них никогда не было опытного фронтенд-разработчика, который бы наблюдал за проектом, его настройкой и архитектурой или обеспечивал наставничество. Что еще хуже, не один менеджер разработчиков полагался на «ниндзя интерфейса», который (при ближайшем рассмотрении) оказался преступно невежественным.
Как это работало раньше?
Аналогичный сдвиг произошел около 8 лет назад, когда в наш мир пришла мобильная связь, новая сложная технология со своими особенностями и областью знаний. Так как же все эти небольшие компании справляются с нативной мобильной связью? У скольких из всех компаний с неудачными проектами внешнего интерфейса, с которыми мы встречались, была команда нативных мобильных разработчиков? Нуль.
В то время как идея взять разработчика серверной части Java и обучить его за неделю, чтобы он начал создавать приложения Angular, кажется хорошей, обучение того же разработчика разработке для Android звучит нелепо для руководства.
нативный язык сложен и выходит за рамки нашего существующего опыта. Черт, да мы бы даже не знали, как проводить собеседования или обучать кого-то.
И все же, держу пари, в соседнем офисе вы найдете 2-3 разработчиков, работающих над огромным приложением Angular, имея лишь смутное представление о «цикле дайджеста», Webpack, Flexbox или о том, как настроить CI. О, и один из них, вероятно, потратил последние 2 месяца на написание классной утилиты, доступной в обычном пакете NPM.
Что случилось?
Является ли фронтенд более сложным, чем любая другая технология? Или, может быть, это так же сложно, как и другие, но не рассматривается как таковое?
Похоже, менеджеров разработчиков можно условно разделить на две группы: гордых и грустных.
Гордые помнят фронтенд со времен своего разработчика в 2006 году. Для них это связка JavaScript и HTML, собранная вместе за несколько часов. Сложные инструменты сборки, большие фреймворки и бесконечное количество сторонних библиотек — это не то, что они готовы принять как необходимое или сложное.
Мы буквально спорили с менеджером по исследованиям и разработкам в стартапе среднего размера, который не мог понять, почему jQuery недостаточно: «В 2007 году я построил сложное SPA, используя только jQuery».
Грустные знают, что они в колее и не знают, как это исправить. Они знают, что если сборка занимает в 3 раза больше времени, а приложение все еще не готово, значит, что-то не так. К сожалению, они оказались в безвыходном положении:
- «Как я могу нанять отличного разработчика интерфейса, если здесь никто не может взять у него интервью и оценить его?»
- «Мы наняли кого-то, но мы действительно не знаем, хорош ли он».
- «По-настоящему хорошие люди не хотят работать в одиночку».
Самопроверка
Если вы думаете: «Мы полностью понимаем, что такое интерфейс, и у нас нет ни одной из этих проблем», спросите себя:
- Ваш внешний код находится в том же репозитории, что и ваш внутренний код?
- Ваш код для iOS и Android тоже находится там?
Вы сказали «Да» первому и «Нет» второму? Время спросить себя, почему.
Что произойдет дальше?
Пройдут ли месяцы или годы, прежде чем сорванные сроки и плохие продукты убедят руководство небольших компаний в том, что интерфейс уже не тот, что раньше?
Когда они смирятся с мыслью, что к фронтенду нужно относиться так же, как и к мобильным приложениям — как к отдельному проекту и предметной области? Или понимаете, что фронтенд сложен и требует специальной команды профессионалов и достаточного времени?
До тех пор у нас останутся неудобные встречи, объясняющие, почему зверь Angular и jQuery, который команда создавала (как они узнали) в течение последних 6 месяцев (и который загружается в Chrome на последнем MacBook занимает 30 секунд), должен быть переписан на React за 2 месяца. Если бы только они остановились и как следует обучили свою команду.
Да здравствует фронтенд!
Первоначально опубликовано на 500tech.com 28 апреля 2016 г.
