Некоторые мысли об архитектуре переднего плана
Проектирование и строительство для перемен.
Когда мы начинаем проектировать или строить новый проект, мы в основном сосредотачиваемся на определении стека, выборе фреймворков и принятии архитектурных решений. В лучшем случае мы ожидаем, что эти решения переживут проект.
Иногда мы откладываем эти решения и сосредотачиваемся на понимании проблемы, создании прототипа и раннем выпуске, чтобы получить ценные отзывы. Но в тот или иной момент некоторые решения были приняты, и только в варианте прототипа мы соглашаемся выбросить большие части кодовой базы и перейти в режим полной перезаписи.
Мы не ожидаем, что придется менять фреймворк или удалять и переписывать существующую кодовую базу, когда решаем реализовать «настоящую» вещь.
Но часто лучший код, который вы можете написать сейчас, - это код, который вы отбросите через пару лет.
Мартин Фаулер, http://martinfowler.com/bliki/SacrificialArchitecture.html
Признание того, что текущая реализация не подходит для решения новых задач, может быть воспринято как провал или как заранее принятые неверные решения. Вы должны были знать об этом заранее, правда? Нет. Очень трудно предвидеть, каким будет конечный результат, а в некоторых случаях его нет, так как продукт будет постоянно развиваться. Чтобы не столкнуться с этой ситуацией, акцент начинает смещаться на случайностях на ранних этапах проекта, без реального понимания того, что нам действительно нужно построить в конце.
Если рассматривать это с точки зрения гибкости, то это то, что на самом деле поощряет гибкая разработка: способность быстро реагировать на изменения. Это означает, что нам нужно найти архитектуру, которая поддерживает возможность быстрой адаптации к изменениям, причем «быстро», конечно, является очень расплывчатым критерием.
Если мы действительно не знаем масштаб или конечный результат большого проекта, для чего мы оптимизируем? Эти решения становятся более сложными на начальном этапе, где изменения являются постоянным фактором.
Добавьте к этому тот факт, что клиенты могут формировать мнения о пользовательском интерфейсе и что эти мнения имеют тенденцию меняться со временем, создает необходимость эффективно реагировать на эти требования. Архитектура, ориентированная на клиентскую сторону, вероятно, более динамична в этом отношении, но разработка серверной части сталкивается с тем же набором проблем.
Если говорить об архитектуре внешнего интерфейса, то постоянный поток новых идей, фреймворков и инструментов - это реакция на развивающуюся динамическую среду. Теперь очевидно, что есть группа разработчиков, которые переписывают свой код каждые две недели только для того, чтобы использовать новейшую библиотеку. Но сейчас нас не интересует эта группа. Решение о переходе на новую структуру - это бизнес-решение. У нас есть ограниченное количество времени, и нам нужно взвесить разные функции.
Принятие и принятие того факта, что нам, возможно, придется переписывать существующее приложение каждые два-три года, является ли это возможным вариантом?
Давайте просто сосредоточимся на том факте, что, хотя мы можем принять решение о React сегодня, это не означает, что мы сделаем это в нашем следующем проекте или даже продолжим делать это в том же проекте. Разве это не то, что даже поощряет гибкая разработка?
Эти решения могут иногда определяться бизнесом, но они также могут определяться размером и зрелостью проекта.
Мы могли бы создать большое приложение с фреймворком, которое решило бы основные проблемы для наших клиентов и добавило огромной ценности, но оно не подходит для следующих шагов. Крупные переписывания не означают, что до этого момента не было добавлено никакой коммерческой ценности или что вся коммерческая ценность потеряна. Можно сменить структуру на что-то более подходящее, учитывая текущие и будущие обстоятельства.
Сделай так, чтоб это работало. Сделать это правильно…
Я вижу, что большая часть сообщества сосредоточена на оптимизации, не придавая особого значения стратегии, как расставить приоритеты для функций, которые необходимо создать. Производительность - наша наименьшая проблема, когда мы начинаем. Основные проблемы связаны со структурой, координацией и эффективностью разработчиков. Есть навязчивая идея с такими словами, как «масштабируемость», хотя очень сомнительно, что масштабирование вызывает беспокойство на самом раннем этапе. Таким образом, вместо того, чтобы приводить вещи в форму и постепенно создавать полезную архитектуру, это сочетание добавления всех инструментов, которые в настоящее время имеют тенденцию, а также заботы о том, как приложение будет масштабироваться, скажем, через 12 месяцев.
Если вы не можете предвидеть масштаб, как может произвольный шаблон сделать это? Похоже, есть необходимость в руководстве, чтобы выбрать один правильный способ создания большого масштабируемого приложения. Команда может либо отложить принятие этих решений, либо согласиться с тем фактом, что выбранные в настоящее время инструменты и структура не могут предвидеть того, что произойдет через пять лет. Это может показаться неприятным, если вы воспринимаете перезапись как провал.
Создание образа мышления, который признает, что архитектура внешнего интерфейса требует постоянных сдвигов и изменений, является частью того, как мы постепенно создаем лучший продукт.
Это звучит очень абстрактно и всегда будет в некоторой степени абстрактным, потому что все зависит от того, как бизнес воспринимает технологии. Это воспринимается как необходимая вещь или рассматривается и понимается как нечто жизненно важное и ключевое для бизнеса?
Чтобы уточнить, это не означает, что мы должны использовать этот образ мышления как оправдание для неправильных решений, это означает, что это реалистичный сценарий, который мы также должны включить в нашу фазу проектирования и оценки.
Я возвращаюсь к сообщению Мартина Фаулера под названием Жертвенная архитектура, где эти идеи обсуждаются и разъясняются с деловой, а также с технологической точки зрения.
Итак, что означает сознательный выбор жертвенной архитектуры? По сути, это означает признание того, что через несколько лет вам (надеюсь) придется выбросить то, что вы строите сейчас.
Мартин Фаулер, http://martinfowler.com/bliki/SacrificialArchitecture.html
Есть несколько вещей, которые было очень трудно достичь на интерфейсе, включая модульность и возможность многократного использования. От эпохи mootools и jQuery до MVC ala Backbone, возможно, первого действительно продвижения к крупномасштабным приложениям с Angular . И даже Angular затруднял написание независимого кода. Эти аспекты со временем стали лучше, но только подумайте о $ http и $ scope, все это очень затрудняло отделение больших частей кода от самого фреймворка. Экосистема Node уже некоторое время продвигает гипермодульные библиотеки, но React действительно принес эти идеи на уровне приложений.
Давайте будем более конкретными. Например, введение функций без сохранения состояния позволяет очень легко написать функцию просмотра без какой-либо трассировки или ссылки на React, по крайней мере, на первый взгляд. Бизнес-логика может быть полностью независимой от фреймворка и даже частично была в Angular, например. За исключением того, что для интеграции внешнего кода в жизненный цикл придется использовать такие вещи, как $ timeout.
Нам также необходимо определить требуемый уровень абстракции, который также может меняться по мере нашего продвижения. Иногда даже лучше продублировать, а затем провести рефакторинг, а затем попытаться абстрагироваться на ранней стадии и разобраться с неправильной абстракцией, которую намного труднее исправить позже.
Возможно, вы не решили внедрять рендеринг на стороне сервера. Это может быть деловое решение, поскольку оно имеет последствия для самого бизнеса. Многие проблемы в JavaScript возникают из-за неправильных решений, а не из-за самих инструментов или фреймворка. Я хочу иметь возможность выбирать между Inferno, Preact и React. Или я могу использовать Cycle.js. То, что кажется множеством подобных решений, на самом деле является роскошью выбора.
Чтобы дать вам пример. Inferno имеет API, очень похожий на React, но если я планирую писать только функции просмотра без сохранения состояния, Inferno становится жизнеспособным вариантом из-за крючков жизненного цикла функций. Чем более агностичны мои решения, тем легче выбросить фреймворк и переключиться на новый. Я хочу сбалансированной оценки. Смогу ли я отключить фреймворк, модуль или библиотеку и по-прежнему использовать части кода? Чем больше разобщенности, тем легче будет это мероприятие. Все это не ново, но сложно реализовать.
Решения должны основываться на том, какую функцию мы хотим внедрить в следующий раз. Возвращаясь к образцу agile, это то, чем занимается product owner. Решите, что будет построено дальше, установив приоритетность невыполненной работы. Или подумайте об этом с другой точки зрения. Если вы попытаетесь включить все популярные инструменты и библиотеки одновременно, вы будете поражены и упустите суть. Важен продукт.
Нужно ли нам делать все правильно с самого начала? Лучше спросить, можем ли мы получить все это правильно с самого начала? Фронт Конечная архитектура должна иметь дело с незнанием всех фактов. Мы не знаем, как тенденции пользовательского интерфейса повлияют на наши решения сегодня. Мы также не знаем, что нас ждет на горизонте с точки зрения технологий, мы можем только предполагать.
Не нужно слишком об этом беспокоиться. В любом случае, всегда рекомендуется держать вещи отдельно, когда это возможно. Хотя я вижу тенденцию, когда сообщество начинает набирать обороты. Решения внезапно превращаются в «единственно правильный способ сделать это». Тесная связь CSS-in-JS с React - одна из тех вещей, которые я заметил в последнее время.
Основное внимание уделяется концепции «как мы можем повторно использовать как можно больше из существующих?». Чем меньше нам нужно переписывать - чем лучше или чем больше мы можем удалить - тем лучше. Но это не значит, что мы должны абстрагироваться или разъединяться ради разъединения. Все сводится к тому, чтобы быть открытым для постоянных изменений, даже принимая их. Реагирование на изменения должно основываться на правильных предположениях, и мы должны подчеркнуть тот факт, что мы находимся в очень динамичной среде, где изменения играют важную роль в принимаемых нами решениях.
