Мы в компании КОРУС Консалтинг СНГ уже больше десяти лет занимаемся организацией разработки веб-сервисов для наших заказчиков. У нас за плечами уже несколько десятков серьёзных проектов в банковской сфере, некоторые из них получили международное признание.
За последние два года количество команд и проектов в нашей компании увеличилось в несколько раз, при этом многократно выросла и эффективность frontend-разработки. Мы научились создавать приложения за несколько недель вместо нескольких месяцев.
Мы постоянно работаем над развитием инфраструктуры нашей фронтенд-разработки, и сегодня я поделюсь некоторыми наработками на тему организации фронтенд-подразделения, которые могут пригодиться тем, кто занимается организацией фронтенда у себя в компании.
Из этой статьи вы узнаете о нашем пути к ответам на следующие вопросы:
- на чём сейчас нужно делать приложения, чтобы они не устарели ещё несколько лет;
- какие фреймворки дают прирост скорости, качества и снижение стоимости разработки;
- как вылечить зоопарк технологий в компании;
- зачем нужен шаблон приложения;
- нужно ли делать собственную библиотеку компонентов интерфейса и как;
- как сильно может вырасти эффективность разработки.
Что такое современный фронтенд
Фронтенд-часть сайта или приложения — это то, что вы видите у себя в браузере, эта часть активно взаимодействует с серверной (backend) частью, которая находится на каком-либо сервере, постоянно обмениваясь с ней данными.
С технической точки зрения фронтенд-часть приложения — это набор файлов, среди которых есть файлы HTML, CSS и JavaScript, картинки и т.п. Работу с CSS и HTML относят к вёрстке, JavaScript — к программированию. Оба этих направления предлагают большое количество инструментов и технологий для работы, активно развиваются и требуют большого количества знаний. Особенно это относится к JavaScript, на котором написано гигантское количество фреймворков и библиотек для «всё более эффективного» создания веб-приложений.
Как-то у меня спросили, на чём сейчас нужно делать приложения, чтобы они не устарели ещё несколько лет?
Как программист, могу дать совершенно точный и совершенно бесполезный ответ: на HTML, CSS и JavaScript. Что конкретно выбрать, jQuery, Angular или React — это уже детали.
Если углубиться в эти детали, можно дать ещё один такой же правильный и бесполезный ответ: на чём угодно. Да, это действительно так. Приложение может быть написано на чём угодно, оно будет работать, его можно будет менять и развивать.
В чём же всё-таки разница?
Чтобы найти ответ, давайте разберём, что хочет бизнес от фронтенда. Я думаю, что никого не удивлю, если скажу, что бизнес хочет быстро и недорого получить качественный результат.
Итак, на чём сейчас нужно делать приложения, чтобы разработка шла быстро, качественно и не разорила заказчика?
Скорость разработки
Программист с большим опытом работы с React сможет быстро написать приложение на React, наличие опыта работы с Angular даёт скорость работы с Angular и так далее. Всё достаточно очевидно. Сами по себе фреймворки экономят время разработки тем, что дают решения типичных проблем и задач. Эти решения по сути могут быть очень близки друг другу, и разница между ними может заключаться в синтаксисе или парадигме программирования.
Скорость разработки с использованием определённого фреймворка зависит от опыта и квалификации программистов, которые на нём пишут, сам фреймворк здесь имеет второстепенное значение.
Качество продукта
Здесь то же самое: и хорошо, и плохо можно писать на любом фреймворке. Можно заложить правильную и неправильную архитектуру куда угодно.
Всё зависит от опыта и знаний разработчика.
Стоимость
Все основные современные фреймворки бесплатны, поэтому, если опустить детали, то стоимость разработки — это стоимость времени, которое разработчики потратили на изучение требований, технологий, проработку архитектуры и написание кода. Плюс стоимость поиска/обучения этих разработчиков.
Отсюда вывод: нужно делать ставку не столько на технологии, сколько на разработчиков и организацию их работы.
Практически любой современный популярный фреймворк достаточно хорош, чтобы на нём создать практически любое приложение, которое может потребоваться современному бизнесу.
Поэтому дальше будет про эффективность фронтенда с точки зрения организации разработки.
Как это было у нас
К 2017 году у нас были приложения практически на всём, что заслуживало внимания в мире JavaScript: от jQuery до разных версий Angular и React на Typescript и Flow. Над клиентской частью наших приложений работали верстальщики и backend/fullstack-разработчики. Каждый разработчик выбирал инструменты под свои задачи, в зависимости от своих знаний фронтенд-технологий.
Сейчас я могу только предполагать, но мне кажется, что выбор фреймворков и библиотек fullstack/backend-разработчиками происходил примерно так:
«Посмотрим, что у нас пишут в интернетах...»
Ну вы поняли.
При выборе фреймворка/библиотеки разработчик ограничен во времени, чаще всего ему некогда самостоятельно разворачивать новые для него фреймворки и делать тестовые приложения. Поэтому он как-то делает более-менее аргументированный выбор и дальше следует в выбранном направлении.
В разные моменты времени этот выбор может быть разным даже у одного и того же разработчика (см. иллюстрации выше). При этом менее аргументированным он не становится. Чего же тогда ожидать от разных разработчиков с разным опытом?
Незаметно к 2017 году мы превратились в настоящий зоопарк фронтенд-технологий.
Фронтенд как отдельное подразделение
Большое количество разных технологий в компании — это источник рисков. Разработчик с нужными знаниями может быть занят на другом проекте, может совсем уйти из компании. Найм специалистов с большим опытом в разных направлениях — тоже занятие непростое.
Качественная документация может смягчить негативные последствия такого разнообразия, но на её изучение и погружение в незнакомые технологии обычно требуется значительное время.
В 2017 году в нашей компании появилось фронтенд-подразделение, которое стало ответом на растущие требования к качеству фронтенд-части наших проектов и к их количеству, а также попыткой стабилизировать разнообразие технологий и повысить эффективность разработки.
Это было важным этапом для развития нашей компании: то, что мы делаем сейчас, невозможно было бы сделать силами разработчиков без специализации на фронтенде.
Как вылечить зоопарк?
Неконтролируемое разнообразие технологий сильно мешает прогнозировать скорость и качество разработки в целом, тогда как коммерческая разработка требует именно этого.
Поэтому нашим следующим шагом стала унификация стека компании силами экспертов нового подразделения.
Унифицированный стек — это строго ограниченный набор библиотек и инструментов, который разработчики могут использовать при решении задач бизнеса. Также туда входит политика в отношении разных подходов в программировании, например, использование преимущественно функционального подхода, или наоборот, отказ от него.
Единый стек даёт разработчику возможность быстро переходить с одного проекта на другой, проводить кросскомандное ревью, эффективно делиться опытом и наработками с коллегами.
Главная задача здесь — не решить, что мы теперь пишем на React или Angular, а сделать так, чтобы разработчики пользовались одинаковыми инструментами для создания приложений и одинаковыми подходами к решению типовых задач.
Для справки: наш основной инструмент — React, но мы также развиваем экспертизу и в Angular.
Вот тут и начинается самое интересное. Принудиловка в мире программирования работает очень плохо.
Поэтому вместо принуждения нужно сделать так, чтобы разработчики сами хотели следовать определённым правилам разработки.
Для этого нужно:
- как-то зафиксировать, формализовать требования к разработке;
- побудить разработчиков следовать этим правилам.
Формализация стека — занятие, которое требует умения держать баланс. Не нужно составлять подробные регламенты всего, чтобы донести основные идеи до разработчиков. Кроме того, создание и поддержание детальных спецификаций отнимает много ресурсов.
Вопрос с мотивацией мы решили следующим образом: лучше всякой документации — дать разработчику полуготовое приложение (шаблон).
Это позволяет разработчикам быстрее решать задачи и впечатлять коллег своей производительностью и одновременно побуждает их придерживаться основных правил, которые уже зашиты в коде.
С одной стороны, похожие друг на друга приложения в итоге дают значительный прирост в скорости разработки за счёт накопления опыта, готовых решений, более глубокого ревью и возможности переходить с проекта на проект. С другой стороны, у каждого проекта есть свои особенности, поэтому здесь тоже важно не перемудрить с шаблонизацией.
Что нужно заложить в шаблон приложения
При старте новых проектов разработчики обычно решают следующие типовые задачи:
- определение архитектуры, подбор технологий/инструментов;
- создание каркаса приложения, сборка;
- создание и настройка общих механизмов: обработка ошибок, модальные окна, уведомления, маршрутизация, запросы к серверу;
- определение набора элементов интерфейса;
- поиск/создание, настройка, стилизация компонентов интерфейса с нужными функциями;
- обработка форм, валидация;
- вёрстка;
- реализация функционала по заказу клиента (бизнес-логика);
- ревью кода;
- ведение документации.
Какие из этих задач ваши разработчики могу решить в течение нескольких минут?
Шаблон приложения, который мы разработали, закрывает первые три пункта из этого списка. Мы выразили в этом шаблоне не только наши пожелания к единому стеку для разработки, но и основные правила архитектуры приложения.
По сравнению с популярными решениями, которые находятся в открытом доступе (например, create-react-app), наш шаблон уже содержит:
- готовую структуру папок;
- настроенный маршрутизатор (routes);
- сконфигурированное хранилище redux;
- модуль запросов к серверу;
- готовые механизмы показа различных типов лоадеров, уведомлений и модальных окон через redux;
- модуль обработки ошибок (серверных и пользовательских) с выводом сообщений пользователю;
- шаблонные страницы;
- шаблонные модули бизнес-логики, к которым подключены обработчики ошибок, лоадеров и уведомлений.
По сути, это production-ready приложение с одной страницей, на которой написано hello world. Начав с утренним кофе, уже к обеду разработчик может показать первую страничку работающего проекта.
Но дальше разработчика ждёт большое количество других интересных (и не очень) задач.
Выбор библиотеки компонентов
Всё, что касается вёрстки, компонентов интерфейса (выпадающих списков, календарей и т.д.), форм и валидации мы решили с помощью собственной библиотеки. Это была самая сложная часть.
В 2017 основной библиотекой компании была платная библиотека компонентов Kendo, которая предоставляла UI-решения для разных технологий, начиная с jQuery. По разным причинам она нас не устраивала, и мы решили рассмотреть альтернативные библиотеки, в том числе и вариант с созданием собственной.
Это очень важный момент, в который нужно сделать правильный выбор: найти другую библиотеку, которая нам лучше подойдёт, или создать собственную. От этого выбора зависит дальнейшее распределение ресурсов разработки и время, которое тратят команды на создание и доработку элементов интерфейса. В своём выборе мы исходили из следующих соображений.
Готовые библиотеки
Плюсы готовых библиотек:
- сразу есть готовый функционал;
- есть готовые решения многих проблем;
- при определённых условиях быстро внедряются.
Минусы готовых библиотек:
- редко удаётся найти сразу полностью подходящее решение (требуется время на поиск, доработки, внедрение);
- доработки компонентов собственными силами возможны до определённых пределов;
- запрос нового функционала невозможен или занимает неопределённое время, что обычно неприемлемо для коммерческой разработки. Функционал приходится дорабатывать самостоятельно;
- исправление багов компонентов занимает неопределённое время, даже в коммерческих библиотеках. Приходится вносить исправления самостоятельно.
Собственные разработки
Плюсы собственных разработок:
- любой функционал по заказу;
- оперативное внедрение новых фич и исправление багов;
- учитывают особенности разработки компании.
Минусы собственных разработок:
- необходимы ресурсы на разработку и поддержку;
- проектам приходится ждать требуемый функционал, иногда по несколько дней/недель в случае со сложными компонентами (календари и т.п.);
- требуется экспертиза в нескольких направлениях (проработка требований, разработка, тестирование, документация).
На деле готовые решения оказываются не такими уж и готовыми. Практически каждую библиотеку нужно в той или иной степени доготавливать. Если вам нужно сделать один небольшой проект, то с такой необходимостью можно и не столкнуться, но если вы делаете какой-то большой проект, или много небольших и разных проектов, то стоимость доработок в итоге может оказаться выше, чем стоимость создания собственной библиотеки, которая полностью удовлетворяет вашим потребностям.
Получается, что приходится выбирать между установкой сразу готового функционала с кучей ограничений и разработкой собственных решений с необходимостью ждать и тратить дополнительные ресурсы на разработку.
Ни один из вариантов нас полностью не устраивал, и мы нашли другое решение.
Мы решили сделать свою надстройку над готовой библиотекой.
Напомню, что на тот момент мы уже пользовались в чистом виде библиотекой Kendo, альтернативу которой мы хотели найти. Именно её мы и решили взять за основу нашей основной библиотеки компонентов для приложений на React. А сама наша новая библиотека представляла из себя фасад над Kendo. Я опущу технические детали, скажу только, что такое решение позволило сразу получить весь функционал Kendo, а то, чего нам не хватало, в том числе и оперативное исправление багов, мы делали сами в прослойке между клиентским API библиотеки и Kendo.
Такая архитектура позволила быстро расширять количество компонентов за счёт других библиотек и модулей, просто встраивая их в нашу прослойку. Для клиентов библиотеки (для разработчиков приложений) это выглядело как быстрый прирост функционала одной библиотеки (об этом я расскажу подробно в отдельной статье).
Со временем мы заменили все компоненты на собственные реализации и выпустили вторую версию библиотеки, где учли весь предыдущий опыт, переработали API и сделали собственную документацию.
Мы решили выложить наши наработки в открытый доступ, скоро их можно будет скачать и использовать в своих проектах, следите за анонсами.
Что в итоге у нас получилось
Сейчас у нас на одном стеке и с одним набором технологий работает больше 10-ти фронтенд-разработчиков в нескольких командах. На одном стеке мы создали уже около двадцати проектов.
Статистика показывает, что эффективность работы за два года выросла более, чем в три раза. Проекты, на которые мы раньше тратили 4-6 месяцев, теперь мы делаем за 1-2 месяца (речь идёт о фронтенд-части).
Мы начали сокращать время разработки за счёт изменения структуры задач программистов. Давайте посмотрим на то, как они изменились.
Я уже приводил список задач, которые решали разработчики два года назад:
- определение архитектуры, подбор технологий/инструментов;
- создание каркаса приложения, сборка;
- создание и настройка общих механизмов: обработка ошибок, модальные окна, уведомления, маршрутизация, запросы к серверу;
- определение набора элементов интерфейса;
- поиск/создание, настройка, стилизация компонентов интерфейса с нужными функциями;
- обработка форм, валидация;
- вёрстка;
- реализация функционала по заказу клиента (бизнес-логика);
- ревью кода;
- ведение документации.
Из них в нашей компании на сегодняшний день разработчики занимаются только последними тремя:
- реализация функционала по заказу клиента (бизнес-логика);
- ревью кода;
- ведение документации по проекту.
Остальное уже решено в шаблоне приложения и библиотеке компонентов.
Это сказалось не только на скорости работы, но и в целом на настроении разработчиков. Как ни крути, реализация бизнес-логики куда интереснее, чем настройка выпадающих списков. Проджект-менеджеру также гораздо проще объяснить заказчику, что неделя рабочего времени была потрачена на разработку важных бизнес-фич, а не на то, что потребовалась доработка небольшого элемента интерфейса, хотя по трудозатратам они могут быть вполне равнозначными.
Мы продолжаем работу в выбранном направлении и одна из основных задач на ближайшее будущее — повышение мотивации разработчиков к углублению компетенций в выбранном стеке и к поиску новых эффективных решений. Масштабирование таких решений на всю компанию теперь не составляет особого труда благодаря общей библиотеке и шаблону приложения.
С пожеланиями эффективности и до новых встреч!