SS
Ilja
место откуда куда зонды вставляют(в просторечье госдума) и не то может
Я не страдаю, так что не по адресу :)
При выборе инструмента для стейт менеджмента, программисты ориентируются на удобство использования и скорость внесения изменений. Но если подумать, то как в основном разработчик формирует мнение о каком-либо инструменте?
Обычно эти качества удобства и скорости разработки либо не тестируются и оцениваются либо по мнению коммьюнити, либо тестируются самостоятельно на небольших кусках приложения или тестовых проектах. К сожалению, очень часто случается так, что “удачные” на первый взгляд решения через какое-то время начинают очень сильно мешать вести дальнейшую разработку.
На мой взгляд, это происходит потому, что получив позитивный опыт использования библиотеки вначале, появляется соблазн выстроить на ней архитектуру всего приложения. И поддавшись этому соблазну, мы можем выкопать себе очень глубокую яму с гвоздями. Например, когда приложение разрастается, то использовать выбранную библиотеку может стать сложнее. Но проблема совсем не в этом, вся беда заключается в том, что мы не можем просто убрать ее из приложения и заменить более подходящим решением — как раз потому, что уже построили на ней всю архитектуру.
Чтобы предотвратить это, стоит не зацикливаться на удобстве библиотеки, а уделить внимание проведению архитектурных границ. Архитектурные границы позволяют откладывать выбор инструмента на потом. Это значит, что мы можем не зависеть от тех правил, которые установлены в библиотеках, а создавать свои правила архитектуры, используя библиотеки как вспомогательный инструмент.
Поэтому если нужно выбрать библиотеку для решения той или иной задачи, то сначала лучше сделать приложение независимым от этой библиотеки, а уже потом переходить к выбору.
