Я выбрал React для разработки приложения, и меня чудом не уволили

«React должен был облегчить разработку, но создал препятствия». С такой проблемой столкнулся архитектор программного обеспечения Разван Драгомир, когда его обвинили в принятии неверных решений на проекте и чуть не уволили. Вот в какую ситуацию он попал… 

Новый проект

Летом 2018 года мой босс Эдриан попросил меня присоединиться к звонку по Skype с CTO крупной канадской компании по имени Джеймс.

Во время знакомства я понял, что Джеймс — умный и крайне амбициозный парень. Его видение заключалось в миграции массивного десктопного приложения WPF в облако. По его дружелюбному настрою я  понял, что он готов сотрудничать с нами. У Джеймса уже был партнер по развитию в Индии, но ему не хватало опыта в создании веб-приложений. Казалось бы, что может пойти не так?

Мы с моим боссом придерживаемся стандартного подхода. Мы проводим еще несколько звонков, а затем переходим в фазу исследования, в которой пытаемся понять общую картину и сформулировать нефункциональные требования. Вот основные моменты, на которых мы должны были сосредоточиться:

1.   Это большое приложение — более 220 страниц. Большая часть — экраны для технического сопровождения, около 20% из них настроены индивидуально.
2.   Надо отображать большие объемы данных, особенно в сетях со всеми видами функций: группировка, возможность заморозить столбцы, расширить строки, настроить столбцы и так далее.
3.   Модульная архитектура, позволяющая нескольким командам работать над проектом одновременно.
4.   Это многолетний проект. Со временем будут добавляться новые функции.
5.   Офлайн-поддержка не требуется.
6. Новичков нужно адаптировать быстро, особенно разработчиков .NET, работающих над старым десктопным приложением.

Я пожалею об этом через два года

Как архитектор я создаю техническое предложение, которое содержит детали архитектуры, подход, дорожную карту, руководящие принципы и, самое главное, стек технологий.

Джеймс несколько раз говорил, что хочет получить технологию будущего. Ему не подходил Angular, потому что, когда AngularJS устарел, фреймворк получил дурную репутацию.

Я уже реализовал несколько небольших и средних проектов как на Angular, так и на React, и знал, что оба справятся с работой. Но по итогу для проекта я выбрал React и Redux. О чем пожалел через два года.

Для работы над доказательством концепции мы собрали команду из трех разработчиков. Через два месяца этап был успешно завершен. У нас были сверхчувствительный UI, невероятно быстрая сборка и высокая скорость разработки. Все были счастливы.

Препятствие #1. К команде присоединяются разработчики .NET

Через некоторое время к нам присоединились разработчики из аутсорсинговой команды клиента. Мы еще не начали встречи для обмена знаниями о проекте, и CTO прислал мне электронное письмо, в котором написал о необходимости наконец приступить к ним. 

На следующий день на встрече технический руководитель засыпал меня вопросами:

• «Где инъекция зависимостей? Как это В ней нет необходимости? Вот пример: InversifyJS!»
• «Функциональные компоненты? Нет, нет, нет. Они нам не нравятся. Давайте работать с компонентами класса!»
• «Почему эти функции просто болтаются в коде? Почему они не инкапсулируются внутри классов сервисов, чтобы сделать их статичными?»
• «Где политика повторных запросов для API? Давайте реализуем ее с помощью PollyJS».
• «Почему в именах файлов тире, если имена классов — PascalCase? Имена файлов должны отражать имя класса, поэтому с этого момента будем называть их SomePageComponent.tsx».
• И вопрос, который выбесил меня больше всего: «Как я могу запустить его с помощью Visual Studio, а не в Visual Studio Code?»

Понимаю, разработчики .NET хотят использовать руководящие принципы .NET и шаблоны проектирования в React. Я сталкивался с этим много раз. Видел, как разработчикам трудно адаптироваться к новым технологиям, поэтому не боялся спорить о том, почему для React эти шаблоны необычны.

Но в этом случае СТО поддерживал свою команду, что, конечно, нормально. В отличии от них, он знал меня всего два месяца. Я должен был пойти на компромисс и согласиться с их предложениями.

Но вдруг я понял, что React не удобен ни Java, ни.NET разработчикам. Angular в этом случае был бы лучшим выбором из-за схожих шаблонов проектирования.

Препятствие #2. Дело не только в React

React неоднозначен. Выработать мнение о том, что и как сделать, и особенно о том, какие другие библиотеки вы хотите использовать — это обязанность вас и вашей команды. Конечно, вы будете применять сторонние библиотеки, потому что не хотите изобретать их заново. И в React полно разных вариантов.

Для подтверждения концепции у меня уже было мнение о том, как нам следует справиться с большей частью сквозных проблем. Теперь их пришлось перепроверять с новыми членами команды. Вот какой минимальный список тем для обсуждения мы составили:

• Какой роутер использовать?
• Что кроме Redux мы должны использовать для асинхронных действий? Thunk? Saga?
• Что мы должны использовать: Axios или fetch API в браузере?
• Redux-Forms, Formiq или Final-Form?
• Styled-Components, makeStyle, SASS или чистый CSS?
• А что с библиотекой интернационализации?

На принятие решений мы потратили еще три недели. Я понимаю, многие скажут, что на выбор библиотек не может уйти три недели, но добро пожаловать на корпоративные проекты!

Есть множество вопросов. Для каждого из них надо создать критерии принятия решения, провести исследование, проверить результаты, создав доказательство концепции, представить результаты, задокументировать все в журнале решений и поддерживать библиотеки в актуальном состоянии. На это уходит сумасшедшее количество времени, и это совсем не весело. 

И это даже без учета времени, которое каждый разработчик тратит на изучение всех этих сторонних библиотек. Я никогда не видел двух проектов React с одинаковыми зависимостями, структурой проекта и руководящими принципами. Это означает, что знания нельзя передавать от проекта к проекту, как это можно сделать в Angular или Vue.

После трех недель без какого-либо прогресса по внедрению функционала из юзер-стори, технический директор забеспокоился.

Препятствие #3. Хуки React становятся популярными

Через девять месяцев мы создали более 50 страниц. Разработчики заметили, что функциональные компоненты ничуть не хуже компонентов классов, и начали использовать их. Проект перестал следовать исходным рекомендациям. Все было больше похоже на личный выбор каждого разработчика. И меня это устраивало.

React Hooks набирали популярность. Разработчики испытывали смешанные чувства.  Одни обижались на предположение, что классы сбивают с толку людей и машины, тогда как другие относились к новому шаблону кодирования с энтузиазмом.

Все сторонние библиотеки, которые мы использовали, добавили поддержку хуков, и, похоже, что весь мир React двигался в этом направлении. Так что же нам было делать? Должны ли мы были отклониться от первоначальных руководящих принципов кодирования и добавить третий способ реализации компонентов? Вернуться назад и перенести существующие страницы и компоненты в хуки было невозможно!

Команда хотела использовать хуки Redux, потому что не было необходимости использовать Redux connect() и отделять dump-компоненты от контейнеров. Это имело смысл, и мы согласились с тем, что отныне новые страницы и компоненты будут использовать хуки. Старые страницы остались как есть.

Итак, у нас было три разных способа писать проект. И не было последовательности.

Что еще хуже, некоторые разработчики начали настаивать на том, чтобы больше не использовать Redux, а вместо него применять useState. Это означало разрушение идеи единого глобального состояния.

Функция Suspense все еще была экспериментальной. Я забеспокоился о том, что произойдет, когда она войдет в релиз.

Препятствие #4. Разработка замедляется

Когда мы настроили непрерывную интеграцию, сборка, включая npm install, занимала около трех минут. Но спустя год она стала занимать около 15 минут.

Нам также пришлось настроить Node.js для увеличения ОЗУ до 4 Гб, потому что 2 Гб было уже недостаточно. Это была небольшая проблема. Что касается начавшихся жалоб на время сборки, горячая перезагрузка переставала работать после 45–60 минут разработки, а перезапуск занимал более пяти минут — особенно у разработчиков с Windows (системы Linux, по-видимому, намного быстрее в смысле Node.JS). Иногда разработчикам на Windows приходилось полностью удалять node_modules и снова загружать зависимости, иначе они просто не работали.

Чего еще можно было ожидать, когда в node_modules более 1200 зависимостей общим размером 600 МБ?

Для корпоративного приложения все сводится к затратам. Допустим, разработчик с почасовой ставкой 40 долларов в час должен перезапускаться шесть раз в день. Шесть раз в день умножаем на пять минут и на 240 рабочих дней в году, затем на 40 долларов в час и на восемь разработчиков, получается $38,4 тыс. в год. Это небольшая сумма для компании, но это был бы хороший годовой бонус для тех, кто платит за проект.

Препятствие #5. Redux-Saga медленно умирает

Большинство разработчиков со мной не согласны, но я думаю, что большая часть бизнес-логики находится внутри асинхронных действий Redux. В большинстве случаев асинхронные действия — единственное место, где можно выполнять проверку, вызовы API, обработку ошибок, запускать redux-мутации или «тостер уведомлений». Если это не бизнес-логика в интерфейсных приложениях, то что?

Оказалось, что мы зря использовали Redux-Saga потому, что это добавило ненужную сложность. Thunk лучше бы подошел.

В корпоративных приложениях нужно иногда обновлять и перепроверять зависимости. Это хорошая практика, потому что важно иметь обновления безопасности, улучшения производительности и небольшие инкрементные изменения API, при этом надеясь на отсутствие критических изменений. Похоже, что Redux-Saga в этом смысле осталась позади. Последнее обновление было давно, количество issues на GitHub продолжает расти, и никто не исправляет их.

Думаю, разработчики любят React по трем причинам: 

• Простота;
• Гибкость;
• Экосистема.

Команде фрейморка нравится экспериментировать, но это убивает экосистему! Они должны проявить смелость и взять на себя вину за это!

React в основном обратно совместим, а экосистема вокруг него — нет. Разработчики и сторонние библиотеки всегда будут использовать новейшие функции и шаблоны архитектуры, а старые эксперименты останутся умирать. Это не должно быть проблемой для малых и средних проектов, потому что вы можете легко адаптироваться. Но для больших многолетних проектов эти эксперименты могут сорвать сделку. 

Продолжим! К сентябрю 2020 года я решил включить React-Saga в результаты оценки рисков, предназначенные для технического руководящего комитета.

Поскольку 30% бизнес-логики находилось внутри Saga, я решил, что это очень рискованно. Именно в этот момент технический директор окончательно вышел из себя и обвинил меня в принятии неверных решений.

Это была искра, в которой нуждался продакт-менеджер. Он использовал ее, чтобы начать задавать следующие вопросы:

• «Почему мы должны тратить столько времени на обновление библиотек?»
• «Почему разработка замедляется?»
• «Почему приложение стало глючным и нестабильным?»

О проблеме узнало руководство. Пришлось долго доказывать, что мы приняли лучшее на тот момент решение. 

Спустя несколько встреч на тему ретроспективы мы снова плыли по спокойным водам. В конце концов, проект почти готов и близок к переходу в режим поддержки.

Заключение

Я люблю React. Я работаю с ним на всех своих личных проектах и с удовольствием порекомендую его для новых инициатив на работе. Однако после такого неприятного опыта я не буду советовать его для использования в корпоративных приложениях. Только не его. И не я один так думаю.