Прошли те времена, когда фронтендеру достаточно было открыть «Блокнот», написать несколько строк кода, проверить его в браузере и загрузить на сервер через FTP. Современная разработка пользовательского интерфейса сильно усложнилась. Экосистема JavaScript растет и изменяется настолько стремительно, что в ней легко запутаться. В этом посте я расскажу, что использует фронтенд-команда Parallels для оптимизации работы.
Уверен, прямо сейчас где-то в мире два фронтендера всерьез спорят о том, какой фреймворк лучше использовать для проекта. И к ним подключается третий — ярый противник каркасов. Он утверждает, что писать нужно на ванильном JavaScript, поскольку все эти прогрессивные приблуды только раздувают код ненужными зависимостями и вообще созданы для тех, кто не умеет программировать. Их дискуссия, скорее всего, ничем не закончится. Спустя час все тихо разойдутся по рабочим местам. Каждый останется при своем мнении и будет работать так, как привык.
На мой взгляд, такие диспуты хуже споров о том, что появилось раньше, курица или яйцо. Потому что единственно верного эффективного решения для беспроблемной фронтенд-разработки не существует. Я согласен с тем, что все основные функции можно сделать, не используя Angular, React, Vue.js и им подобные фреймворки. Но если цель — сотрудничество и вы создаете крупномасштабное приложение не один, а в команде, с ними проще.
Безусловно, можно обойтись и без них, но они дают возможность не тратить время на создание стандарта, задают структуру (всегда знаешь, что где лежит), облегчают рутину и ускоряют разработку. Если считать, что язык — это алфавит, то фреймворк можно рассматривать как разговорник с диалогами-клише, позволяющими легко выстроить общение.
В этом посте я поделюсь полезными инструментами, которые мы с командой используем при создании пользовательского интерфейса. Они значительно упрощают как совместную разработку, так и дальнейшую поддержку проекта.
***
Думаю, для начала стоит рассказать немного о себе. В мир IT я попал девять лет назад, в 2011 году. Начинал как фулстэк в одной небольшой организации. Потом занимался гибридными мобильными приложениями, отвечал за часть логики, которая находилась в WebView. И спустя несколько лет оказался в Parallels. Здесь я работаю в команде Cloud, которая является поставщиком веб-решений для всех продуктов компании. Основная часть бизнес-фич требует от меня продумывания и реализации фронтендных задач. Сейчас сфокусирован на разработке портала My Account.
Как вы уже, наверное, поняли из текста выше, создание интерфейса этого веб-приложения не обошлось без фреймворка. Мы выбрали Vue.js. Чтобы с ним было приятно работать, развернули также дополнительные инструменты. Вот, что помогло нам максимально оптимизировать процесс разработки.
Vue CLI
Эта утилита командной строки включает в себя очень много полезных фич и предназначена для быстрой разработки проектов. Грубо говоря, она создает стандартную основу для запуска и позволяет сосредоточиться на создании приложения, не думая на первоначальном этапе о средствах и конфигурации сборки. Их можно настроить под нужды проекта позже.
Vue CLI обеспечивает поддержку основных технологий веб-разработки. Из коробки идут такие инструменты, как Webpack, Babel, TypeScript, ESLint, Sass. А, кроме того, есть встроенная поддержка модульного и сквозного тестирования с помощью Mocha и Nightwatch.
Vue Devtools
Расширение для браузера, которое позволяет делать отладку приложения в режиме реального времени. В нем есть доступ к свойствам и методам компонентов, список всех событий. Можно полностью управлять состоянием приложения через веб-страницу и не ждать переборки, чтобы увидеть результат.
Работает в Chrome и Firefox. Официального расширения для других браузеров нет, но можно запустить Vue Devtools через приложение Electron. Тогда инструмент будет доступен в любой среде.
Zeplin
Сервис делает передачу макетов в разработку удобной. Как и в любой крупной компании, у нас есть набор UI-компонентов. Раньше он лежал в PSD файлах и из-за этого доступ к нему был очень хаотичный. А в Zeplin есть такая вещь, называется глобальный стайлгайд.
В нем можно собрать все правила построения корпоративных интерфейсов. Для каждого UI-компонента автоматически генерируется CSS код — указаны цвета, размеры, отступы и прочие свойства каждого блока, из которых состоит элемент. То есть стили больше не нужно каждый раз реализовывать с нуля, что очень ускоряет работу. PSD эра закончилась.
Плюс, там есть история всех изменений. Можно легко отследить, как было на начальном этапе и что получилось в конце.
Git url as dependency
Это фича npm, которую мы используем. Нам нужно было расшарить набор UI-компонентов, чтобы коллеги внутри компании имели к нему доступ и могли применять для своих нужд. Самое очевидное решение этой задачи — npm-пакет. Но нам не хотелось, чтобы он был в публичном реестре, локальный npm-сервер оказался не совсем хорошей идей, поэтому использовали связку git+npm.
Таким образом, у каждого сотрудника Parallels есть доступ к кодовой базе UI, а поскольку это git, то решена также проблема версионирования. Из-за обновлений не возникнет проблем, ничего ни у кого не сломается.
Sentry
Чтобы собирать ошибки и логи, которые происходят на стороне клиента, не дожидаясь жалобы, мы подключили Sentry. Этот инструмент отслеживает исполнение кода в браузерах кастомеров.
Если вылезает какой-то баг, нам автоматически отправляется запрос с полным отчетом, отражающим как суть произошедшего, так и список действий, который этому предшествовал. По этим данным очень просто найти причину и все исправить.
Также это позволило немного разгрузить нашу техподдержку, избавили коллег от лишних звонков и обращений.
О вреде зависимостей
Напоследок — маленький совет. Старайтесь писать утилиты сами. В последнее время библиотеки с готовыми решениями стали очень популярны. Доходит до того, что фронтендеры берут зависимости даже для «однострочных» функций, которые могут написать с закрытыми глазами. Чем это грозит? Сбоем.
Четыре года назад произошла поучительная история. Один человек удалил свой 11-строчный пакет из реестра npm и сломал тем самым около тысячи проектов. Разработчики по всему миру начали получать сообщения об ошибке при попытке развернуть свои приложения из-за отсутствия крошечного модуля с именем «left-pad».
Так что не ленитесь, не заменяйте код связкой зависимостей. Полагайтесь на себя и пишите мелкие утилиты сами, а готовые библиотечные решения используйте только для сложных функций — там, где они действительно помогают не изобретать «велосипед».
Автор: alexvinogradors
