Около десяти лет назад сообщество веб-разработчиков впервые начало обсуждать концепцию "Single-Page Application" и искать способы ее реализации. К тому моменту разработка графических интерфейсов уже не являлась чем-то новым и поэтому многие вещи заимствовались у существующих решений и немного адаптировались под специфику браузеров.

Наиболее успешным результатом подобной работы оказался Backbone.js — объектно-ориентированный MVC-фреймворк, который в свое время использовался в BitBucket, Basecamp, Stripe, Airbnb и Trello. Со временем он был полностью вытеснен следующим поколением фреймворков, но...

Что если бы этого не случилось? Как бы тогда выглядела современная разработка веб-интерфейсов?

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

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

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

NB: В качестве примеров в статье будут использоваться только те фреймворки, с которыми непосредственно имел дело автор, и существенное внимание здесь будет уделено React и Redux. Но, несмотря на это, многие описываемые здесь идеи и принципы носят общий характер и могут быть более-менее успешно спроецированы на другие технологии разработки интерфейсов.

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

— Это слишком дорого, что если сделаем без функции Х?
— *делаем расчет* Столько.
— Все равно дорого, а сколько будет стоить разработка только под платформу Y?
— *делаем перерасчет* Столько.
— Ух ты, то есть, если мы откажемся от платформы Y, то сможем сделать не только Х, но и Z?
— *очередной перерасчет* Увы, нет.
— Жаль, тогда давайте сделаем без Z, во сколько нам обойдется?

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

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