Меняйте и масштабируйте свое приложение изящно  — важность фреймворков

В первые дни программирования я был так разочарован и всегда заканчивал тем, что отказывался от проектов, потому что я просто не мог довести их до определенного предела.

Я начал с разработки игр на Unity, и у меня всегда были идеи о том, как постоянно улучшать их, добавляя новые функции и избавляясь от тех, которые мне не нравились.

Я был и бизнесменом, и инженером, и всегда заканчивал тем, что требовал от себя полного переписывания, одобрял их, а затем бросал работу от скуки.

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

Но я все еще не мог полностью решить первоначальную проблему:

разработка системы, которая может масштабироваться и изменяться.

Программное обеспечение постоянно меняется

Я не осознавал, насколько итеративным является процесс разработки программного обеспечения.

Я часто не знал, насколько хороша функция, пока она не оказывалась прямо передо мной.

Я так увлекся их реализацией, что сразу влез в технический долг.

После внесения некоторых изменений я делал перерыв, а потом через несколько дней возвращался, смотрел на код и не мог не думать:

«Эта реализация очень неуклюжая. Это нужно переписать с нуля».

Через какое-то время после многих проб и ошибок большинство предположений, лежащих в основе первоначального дизайна, оказались ложными. Ничто больше не имело смысла, даже для меня, написавшего этот код.

Мы не можем избежать этой проблемы, потому что программное обеспечение должно развиваться и адаптироваться, как и мы. Потому что рано или поздно кто-то сделает то же самое, только чуточку лучше.

Легко и весело

Была и еще одна причина моих неудачных попыток. Мне не хватало (и очень не хватает) дисциплины.
Вообще, нам, людям, нравится легко и весело.

Для меня это плохие новости, потому что мне очень нравится JavaScript, и с его помощью можно делать много сумасшедших вещей, которые вы никогда больше не поймете.
Я обнаружил, что

единственное, что убедило меня сделать это долго, скучно, но правильно, это ошибка времени выполнения или компилятора.

Я не совсем хотел или мог создать свой собственный язык, вместо этого я смотрел на фреймворки.

Они не так хороши, как компиляторы, но у них все же есть твердое мнение о том, как вы должны что-то делать.

Как выглядит плохая архитектура?

Какая самая простая архитектура возможна для веб-приложения?

1. Генерируется исходный DOM.

2. Время от времени происходят события, и их обработчики модифицируют DOM.

3. Конец.

Почему это плохо?

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

Как выглядит гораздо лучшая архитектура?

Точно такой же, как плохой, но теперь бизнес-логика отделена от всего, что связано с DOM.

1. Генерируется исходный DOM.

2. События происходят время от времени, и их обработчики создают действия (простые объекты JS, повторяющие изменение), которые изменяют состояние приложения (может быть таким же простым, как обычный объект JS).

Мы определяем функцию reduce, которая принимает старое состояние и действие («изменение») и возвращает новое состояние.

reduce(state, action) -> newState

3. Мы определяем функцию render, которая принимает состояние приложения и генерирует (виртуальную) модель DOM, а платформа вызывает эту функцию каждый раз, когда состояние изменяется в результате события:

рендеринг(состояние) -> виртуальныйDOM

Почему это хорошо?

1. Бизнес-логика не имеет ничего общего с DOM — только знает о состоянии, которое является простым JS-объектом.

2. Требуются две гигантские чистые функции (reduce и render), с которыми намного проще работать и тестировать.

3. Поскольку с reduce и render легко работать, вы можете легко разбить их на более мелкие части (компоненты).

4. Много маленьких простых элементов гораздо легче изменить, чем большие и сложные.

Эта архитектура является основной идеей Elm.
Redux был вдохновлен Elm.
HyperApp был вдохновлен Elm.

Так как же создать приложение, которое можно масштабировать и выдерживать изменения?

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

Я рекомендую HyperApp. Он очень маленький, очень простой в освоении и содержит множество замечательных концепций.

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

Не забывайте, что JavaScript никогда не предназначался для того, что он делает сейчас.