Когда у меня еще не было глубокого понимания ReactJS, я стал свидетелем архитектурного решения, которое стоило компании несколько миллионов на старте и повысило стоимость и сроки разработки в последующие годы. Речь идет о решении прийти к единому стеку для всего IT-отдела, и для веб-интерфейса был выбран React. Проблема заключалась в разнообразной специфике команд - как внутренних, так и внешних, - работавших над продуктами для разных клиентов. Ситуацию усугубляла низкая экспертность в выбранном стеке у единственного архитектора и разработчиков, что потребовало найма новых специалистов, в том числе и меня.

На этом этапе затраты только начинались, но сначала расскажу, почему ReactJS стал очевидным кандидатом - чтобы обнажить имеющиеся проблемы. В отличие от фреймворков, ReactJS не диктует правил, как на нем писать, и понимание этих правил обычно приходит с опытом работы на разнообразных продуктах. Эта библиотека требует глубокого понимания своих принципов, например, компонентного подхода. Без понимания того, как правильно разделять страницу на компоненты, невозможно использовать React на 100%. И даже этих знаний будет недостаточно, чтобы независимые части интерфейса не перерисовывали друг друга без необходимости. Здесь понадобятся практические знания управления состоянием.

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

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

Для обсуждения конкретных примеров проектов, которые я видел, потребовалась бы отдельная статья, поэтому здесь я ограничусь замечанием, что ни один из них не был похож на другой, и перейду к архитектурному решению, упомянутому в начале. Проект, который переносили, был написан на Vue и удовлетворял многим потребностям: в нем даже джунам было легко вносить правки, не тянувшие за собой новые баги. Я ощутил это лично - пришел с нулевым опытом работы на Vue, но быстро начал брать задачи любой сложности. Этот фреймворк будто бы однозначно и четко подсказывал, где и как писать код. Фичи реализовывались так же быстро, поэтому клиенты были довольны надежной системой, успевавшей за их потребностями.

Но длилось это недолго: во время перехода нагрузка на команду возросла, проект на Vue замедлился, а новый продукт затянулся из-за некоторых фундаментальных ошибок…

Продолжение - в комментариях 👇