React - зеркало архитектурных ошибок
Когда у меня еще не было понимания ReactJS, я стал свидетелем архитектурного решения, которое стоило компании несколько миллионов на старте и повысило стоимость и сроки разработки в последующие годы. Речь идет о решении прийти к единому стеку для всего IT-отдела, и для веб-интерфейса был выбран React. Проблема заключалась в разнообразной специфике команд - как внутренних, так и внешних, - работавших над продуктами для разных клиентов. Ситуацию усугубляла низкая экспертность в выбранном стеке у единственного архитектора и разработчиков, что потребовало найма новых специалистов, в том числе и меня.
На этом этапе затраты только начинались, но сначала расскажу, почему ReactJS стал очевидным кандидатом - чтобы обнажить имеющиеся проблемы. В отличие от фреймворков, ReactJS не диктует правил, как на нем писать, и понимание этих правил обычно приходит с опытом работы на разнообразных продуктах. Эта библиотека требует глубокого понимания своих принципов, например, компонентного подхода. Без понимания того, как правильно разделять страницу на компоненты, невозможно использовать React на 100%. И даже этих знаний будет недостаточно, чтобы независимые части интерфейса не перерисовывали друг друга без необходимости. Здесь понадобятся глубинные знания управления состоянием.
Одной теории окажется мало: экосистема React полна библиотек, каждая из которых подходит для проектов разного масштаба. Неправильно выбранный стек вокруг ReactJS приведет к проблемам, которые могут проявиться уже на этапе эксплуатации, когда обратного пути не будет. Также React требует контроля нового кода: при отсутствии правил проекты на нем подвержены тому, что каждый разработчик пишет по-своему. Я часто наблюдал такое явление, что приводило к усложнению понимания отдельных участков кода и проблемам с его поддержкой.
Следовательно, на новых проектах критически важно задать правильную архитектуру, а для специалистов, участвующих в переходе, - проводить постоянное ревью кода. При отсутствии возможности нанять опытных специалистов, что само по себе затратно, быстро обучить своих сотрудников этим ролям не получится, так как React требует значительного практического опыта - как в понимании его принципов, так и экосистемы.
Для обсуждения конкретных примеров проектов, которые я видел, потребовалась бы отдельная статья, поэтому здесь я ограничусь замечанием, что ни один из них не был похож на другой, и перейду к архитектурному решению, упомянутому в начале. Проект, который переносили, был написан на Vue и удовлетворял многим потребностям: в нем даже джунам было легко вносить правки, не тянувшие за собой новые баги. Я ощутил это лично - пришел с нулевым опытом работы на Vue, но быстро начал брать задачи любой сложности. Этот фреймворк будто бы однозначно и четко подсказывал, где и как писать код. Фичи реализовывались так же быстро, поэтому клиенты были довольны надежной системой, успевавшей за их потребностями.
Но длилось это недолго: во время перехода нагрузка на команду возросла, проект на Vue замедлился, а новый продукт затянулся из-за некоторых фундаментальных ошибок.
Расскажу о некоторых из них:
1. Для уменьшения веса сборки было принято решение использовать чистый Tailwind CSS без дополнительных UI-библиотек. Это оправдано для внешнего продукта, где требуется уникальный кастомный интерфейс, но не для внутреннего продукта при отсутствии дизайнера. Такое решение замедлило переход, усложнило создание фич и сместило акцент с надежности функционала на необходимость тратить время на реализацию собственных компонентов и дизайн.
2. Не было принято общего решения по управлению состоянием, поэтому каждый писал в силу своих знаний: для форм использовались хуки и провайдеры из useForm, для других задач - проброс пропсов или React Context. Это усложняло проект, превращая его в своего рода Франкенштейна, и требовало отдельного внимания к работе джунов, чего не всегда удавалось обеспечить в условиях высокой нагрузки. Продукт стал сложным для поддержки, раздулся по объему кода и работал медленнее, чем ожидалось, уже в первые месяцы после релиза в продакшене. Несмотря на то что на весь срок перехода мы отдельно нанимали архитектора и даже заменяли его на другого, это не помогло. Проблемы были не только в нехватке релевантного практического опыта, но и в отсутствии четкого представления о нашей целевой аудитории и ее взаимодействии с продуктом.
Что касается React, он стал лишь отражением перечисленных ошибок и не является чем-то плохим. Я часто использую эту библиотеку в работе и в целом положительно о ней отзываюсь, но призываю быть внимательнее: проблемных продуктов на React я встречал чаще, чем архитектурно выстроенных.
Изучайте реальные возможности своей компании - не только при принятии часто утопических решений, таких как унификация стека для большого числа команд, но и при выборе технологий для нового продукта. Лучше потратить дополнительные ресурсы на анализ, чем столкнуться с необратимыми проблемами на долгие годы.
Спасибо за внимание. Не стесняйтесь участвовать в обсуждении и задавать вопросы в тг: @pro_kod или в комментариях.