Как Меня Чуть Не Уволили За То, Что Я Выбрал React Для Корпоративного Приложения

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

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

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

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

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

Итак, я уже успешно реализовал несколько небольших и средних проектов как на Angular, так и на React, поэтому не привязан к какому-то одному фреймворку.

И я считаю, что обе платформы справятся со своей задачей.

Для этого проекта я выбираю React и Redux. о чем пожалею два года спустя.

Мы назначили команду из трех разработчиков для проверки концепции и успешно завершили ее в течение двух месяцев.

У нас был невероятно быстрый пользовательский интерфейс, такая же быстрая сборка и быстрая скорость разработки.

Все были счастливы.

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

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

Мы еще не начали встречаться, чтобы поделиться знаниями о проекте, и технический директор прислал мне электронное письмо со словами: «Привет, Разван.

Завтра нам действительно нужно встретиться с моей командой по аутсорсингу».

Итак, мы на встрече; Технический менеджер забрасывает меня вопросами:

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

Все становится яснее.

Разработчики .

NET хотят использовать рекомендации и шаблоны проектирования .

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

Он знал меня всего два месяца, но работал со своей командой много лет. Я должен пойти на компромисс и согласиться на их предложения.

И тогда я понял, что React не дружелюбен ни к Java, ни к .

NET-разработчикам.

В этом случае Angular будет лучшим выбором из-за схожих шаблонов проектирования.

2. Дело не только в React.

React — это библиотека, у которой нет своего мнения; это означает, что у нее нет мнения о том, как решать проблемы, затрагивающие все аспекты.

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

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

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

Теперь их пришлось повторно тестировать с новыми членами команды.

Вот минимальный список тем для обсуждения:

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

Итак, мы потратили еще три недели на принятие этих решений.

Я уже слышу, как ты восклицаешь: «Чувак! Не может быть, чтобы выбор этих библиотек занимал три недели!» Что ж.

добро пожаловать в корпоративные проекты.

Есть много решений.

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

Это занимает безумное количество времени и не приносит удовольствия.

И я даже не учитываю, сколько времени каждый разработчик тратит на изучение всех этих сторонних библиотек.

Я никогда не видел двух проектов React с одинаковыми зависимостями, структурой проекта и рекомендациями.

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

3. Хуки React набирают популярность

Девять месяцев спустя мы создали более 50 страниц.

Разработчики заметили, что функциональные компоненты ничем не уступают компонентам класса, и начинают их использовать.

Итак, теперь проект не следует первоначальным рекомендациям по кодированию.

Все это больше похоже на личный выбор каждого разработчика.

И для меня это нормально.

React Hooks набирает популярность.

У разработчиков смешанные чувства.

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

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

так что нам делать? Должны ли мы отступить от первоначальных рекомендаций по кодированию и добавить третий способ реализации компонентов? Больше невозможно вернуться назад и переместить существующие страницы и компоненты в хуки! Команда выступает за использование перехватчиков Redux, поскольку нет необходимости использовать Redux Connect() и отделять «глупые компоненты» от контейнеров.

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

Старые страницы останутся как есть.

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

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

Функция «Приостановка» все еще находится на стадии эксперимента.

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

4. Развитие замедляется

Когда мы настроили непрерывную интеграцию (CI), сборка, включая установку npm, заняла около трёх минут. Но сейчас, год спустя, это занимает около 15 минут. Нам также пришлось настроить Node.js и установить 4 ГБ оперативной памяти, потому что 2 ГБ уже было недостаточно.

Это не большая проблема.

Что касается жалоб на время сборки, то горячая перезагрузка перестает работать после 45-60 минут разработки, а перезапуск занимает более пяти минут — особенно для Windows-разработчиков (системы Linux, видимо, намного быстрее в смысле Node.JS).

Иногда разработчикам Windows приходится полностью удалять node_modules и загружать зависимости заново, потому что иначе они просто не работают. Чего еще можно ожидать, когда node_modules имеет более 1200 зависимостей общим размером 600 МБ? Что касается корпоративного приложения, все сводится к стоимости.

Допустим, разработчик с почасовой ставкой 40 долларов в час должен перезагружаться шесть раз в день.

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

В конце концов, сумма эквивалентна новенькой Tesla Model 3.

5. Redux-Saga медленно умирает

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

Если это не бизнес-логика во фронтенд-приложениях, то что это? Решение использовать Redux-Saga оказалось плохим, поскольку оно добавляет ненужную сложность.

Танк вполне бы подошел.

В корпоративных приложениях необходимо время от времени обновлять и перепроверять зависимости.

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

Похоже, Redux-Saga в этом смысле осталась позади.

Последнее обновление было больше года назад, количество проблем на GitHub растёт, а их никто не исправляет. Разработчики любят React по трем причинам: простота, гибкость и экосистема.

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

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

Но в случае крупных многолетних проектов такие эксперименты могут отбить у клиента желание работать с продуктом.

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

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

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

Это была именно та искра, которая была нужна менеджеру по продукту.

Эта искра дала менеджеру возможность задать вопросы, такие как:

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

Ситуация доходит до уровня управления.

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

После нескольких ретроспективных встреч мы снова плывем по спокойной воде.

В итоге проект почти готов и близок к переходу в режим поддержки.

Заключение

Я люблю Реакт. Я работаю с ним над всеми своими личными проектами и буду рад порекомендовать его для новых инициатив на работе.

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

Не это.

И я не одинок в этом.

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

Другие профессии и курсы ПРОФЕССИИ

КУРСЫ

Теги: #программирование #Читальный зал #стартап #JavaScript #SkillFactory #react.js #react #angular #react

Последнее изменение: 2024-10-19 21:10:22

Вместе с данным постом часто просматривают: