Декларативность. Лаконичный и оптимизируемый код

Тезисы

Декларативность. Лаконичный и оптимизируемый код

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

1) Декларативное описание того как используется результат (зачем вы что-то делаете, целеполагание)
2) Декларативное описание от каких состояний зависит результат (что нужно чтобы выполнить задачу)
3) Способ вычисления результата (как распорядится ингридиентами, чтобы получить необходимое)

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

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

Требования к приложению и ограничения
  Принципы проектирования интерфейса: zoom ui, формир. привычек, нет модальным оконам, максимум данных
  на минимум действий пользователя, 3 правила высокоскоростного взаимодействия интерфейсов (http://habrahabr.ru/post/211659/).
  Требование к продукту: кол-во страниц, кол-во взаимодействий с сервером, производительность.
  Технические: только сообщения между view и model, возможность полностью восстановить состояние,
  ограниченное количество запросов.

Лаконичность, оптимизируемость и отсутствие сложности: разделить V и M; разделить описание
взаимосвязей и вычисление; описывать желаемый результать, а не шаги к его достижению.

Оптимизации: JS - кэш, кэш, кэш, GC, inlining. DOM (http://habrahabr.ru/post/210558/).

Ещё производительней - приоритезация вычислений, анализ css.
Ещё лаконичней - точные автоматические запросы на основе деклараций используемых
состояний из кода и шаблонов; joins.

О сложностях создания seesu.me — приложения для поиска и прослушивания музыки. О принципе написания сложного кода лаконичным и оптимизируемым. Об оптимизациях JS и DOM.

1. Интерфейс по заветам Джефа Раскина, высокоскоростное взаимодействие без производительности http://habrahabr.ru/post/211659/, технические ограничения.
2. Укрощение сложности, лаконичность. Принцип разделение кода: 1) на что влияет результат 2) от чего зависит результат 3) как вычислить
3. Оптимизации: JS - кэш, кэш, кэш, GC, inlining. DOM http://habrahabr.ru/post/210558/.
4. Ещё больше оптимизаций и лаконичности в будущем. (?)

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

Если бы кулинарный рецепты содержали в себе инструкции о том как дойти до магазина, как дойти до полки и взять некий предмет не сообщая о том, что же вы берете, кому они были бы полезны?

Идеальный рецент - это

1. то, что у вас получится, название для чего-то сложного
2. список необходимых компонентов (понятный без прочтения всего рецепта)
3. инструкция по использованию компонентов

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

Так, сбором необходимых компонентов могут заняться люди не являющиеся поварами — курьеры, логисты, SQL программисты, а повар может сосредоточится на приготовлении тортов. Перемещение готового торта за пределами кухни — тоже не его дело.

Аналогичным образом связность сложных состояний приложения мог бы обеспечивать язык программирования/фреймворк/библиотека

1. Декларативное описание того как используется результат (зачем вы что-то делаете, целеполагание)
2. Декларативное описание от каких состояний зависит результат (что нужно чтобы выполнить задачу)
3. Способ вычисления результата (как распорядится ингредиентами, чтобы получить необходимое)

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

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