Предисловие: Эта статья составлена на основе моих собственных проблем в Чжиху.«Есть ли «архитектура» для интерфейса в 2018 году?»ответ. Говорят, что у Наггетс есть записная книжка, выпущенная ограниченным тиражом, поэтому я организовал ее в статью и разослал. Если вам также нравятся блокноты Nuggets, вы также можете публиковать статьи.
кожа
Во-первых, уточните определение архитектуры.В этом вопросе Zhihu субъект сказал, что «вся внутренняя архитектура очень сложна и огромна, и хороший архитектор должен сделать выбор архитектуры среди бесчисленных комбинаций решений». Может показаться, что архитектура — это вопрос выбора среди множества компонентов решения.
Поэтому, если вы ответите «есть много комбинаций фронтенд-решений, поэтому архитектура тоже очень хлопотная», сможете ли вы ответить на этот вопрос? Итак, много ли комбинаций интерфейсных решений? Это действительно много, гораздо больше, чем задняя часть.
Сверху — кончики рогов.
1. Опасения
Целью внутренней архитектуры, как уже упоминалось в теме, является высокая производительность, высокая доступность, масштабируемость и безопасность.
Что касается многих пунктов знаний, упомянутых позже, хотя все они полезны, они неизбежно выпадают из книжного портфеля. Существуют различные трудности с высокой доступностью, и есть различные аспекты высокой доступности, требующие внимания, но на самом деле после стольких лет разработки в бэкенде, особенно после появления большого количества пользовательских сценариев, решения этих проблемы также очень ясно. Если это неясно, это также признается отраслью как временно неразрешимая проблема, такая как распределенная CAP. Что же касается конкретных технических стратегий конкретных встречающихся проблем, то если вам все же нужно подумать об этом самостоятельно, то back-end инженер (не называемый архитектором) должен быть неквалифицированным. Я понимаю, что архитектура бэкенда — это в основном выбор среди решений для различных сценариев, разобранных предшественниками.
Что насчет передней части? Являются ли цели также высокой производительностью, высокой доступностью, масштабируемостью и безопасностью? Так до тех пор, пока не нужно выбирать базу данных, не нужно выбирать язык, а фреймворк выбирает один из трех, архитектура проста? Я думаю, что это является отражением плохого понимания интерфейсных задач.
2. Основной фокус фронтенда — пользователи
Что вас беспокоит как фронтенд-инженера? Во-первых, это пользователь, включая работу и пользовательский опыт на стороне пользователя.
Например, пользователю предоставляется интерфейс, например, красный текст сообщения об ошибке или поле ввода становится красным? Загрузка сверху или посередине страницы? После того, как пользователь нажмет кнопку «Отправить», отображается ли кнопка «Загрузка» или она неактивна? Перевернуть хризантему или экран-скелет? Сначала показать замещающее изображение или сначала пустой экран?
Другой пример: доволен ли пользователь посещением моего веб-сайта, приятно ли им пользоваться, будет ли он чувствовать себя застрявшим, будет ли он чувствовать себя подавленным. Эти вещи будут определять, является ли ваша страница одностраничной или многостраничной, как разработан URL-адрес и какова стратегия загрузки?
Я думаю, что это те вещи, на которых передняя часть должна сосредоточиться больше всего.
Так что архитектура, которую я делаю, совсем не высокая. Просто решите, как ускорить загрузку веб-сайта, как не вводить ненужный код, избавиться от ненужного кода, как позволить пользователям загружать наименьшее количество контента, как позволить пользователям быстрее увидеть эффект, внешний рендеринг или внутренний. рендеринг, синхронизация вывода или асинхронный вывод и так далее.
Думаете, это совсем не работа архитектора? Но фронтенд-архитекторы делают именно это. Поэтому, если вы хотите сказать, что фронтенд-архитектор — это технический архитектор, лучше сказать, что это архитектор опыта, который больше заботится о пользователях. С этой точки зрения фронтенд-архитекторы и бэкэнд-архитекторы не сосредотачиваются на одном и том же измерении.
3. Инженерная сложность
Владелец темы сказал: «В лучшем случае вы можете посчитать решения, ориентированные на эксплуатацию и обслуживание, такие как мониторинг ошибок, решения скрытых точек и стратегии кэширования». приговор.
Да, внутренний мониторинг ошибок не сложен, не болееtry..catchЧто ж, каким бы плохим ни был процесс, все равно существуют различные средства эксплуатации и обслуживания, способные спасти людей. Но как насчет передней части? ОдинajaxКак контролировать, если загрузка не удалась, одинcssКак отслеживать, если загрузка не удалась, если она более экстремальная, как отслеживать, не зависает ли браузер, как отслеживать, не падает ли страница?
Что касается захоронения, то я им очень восхищаюсь. Даже если пользователи закроют вашу страницу, вы не сможете ее отследить.Вы все равно хотите получать деловые и технические данные, закапывая точки?
Насчет кеша еще более странно.Есть ли кеш?200все еще304Запроса до сих пор нет, в итоге версия правильная, не перепутал ли его прокси, в конце концов как этот волшебный браузер обрабатывает кеш... Не думайте, что говорить "добавьте кеш", это так легко это сделать. Каждый фронтенд-инженер, хорошо играющий в кеш, заслуживает уважения. не говори больше ничегоlocalStorage/serviceWorkerи так далее.
Говоря об этом длинном абзаце, я не хочу сказать, что фронтенд-архитекторам очень тяжело и утомительно это делать, вы должны нас уважать. Но я хочу сказать, что эти незаметные вещи не так просты, как кажется, архитекторы часто помогают инженерам исследовать или ходить по карьерам, чтобы получить технические решения для этих вещей.
В-четвертых, для команды
Фронтенд-инжиниринг на данном этапе еще незрелый, что является реальной ситуацией. Пока архитектор выбирает проект, значительная часть его сил уходит на подбор инженерного решения. использовать лиwebpack, использовать лиnpm, использовать лиTypeScript, использовать лиES6/7/8, стоит лиbabel, использовать лиPostCSS. Хотите ли вы CI, хотите ли вы автоматически упаковывать и выпускать. Следует ли загружать подпакеты, извлекать ли файлы CSS...
Этих вещей может не быть в бэкенде, может не быть в клиенте, а даже если они и существуют, то их незаметно делает IDE. В качестве селектора проекта напишите несколько зависимостей,installСразу начал работать. Но внешний интерфейс не очень хорош, в нем много инженерных задач по подбору или настройке/разработке.
Как архитектор, нелегко выбрать язык/инструмент сборки, который прост в использовании и не имеет подводных камней.
Приведу пример: вы можете подумать, что TypeScript очень хорош, так почему бы не использовать его напрямую? Как всем известно, TypeScript требует настройкиtscилиwebpackизts-loader(в настоящее времяbabelтоже нормально)tsconfigдокументы и различные.d.tsдокумент. Конечно, даже в этом случае можно сообщить кучу неразрешимых ошибок при написании кода, и нужно потратить много времени на изучение того, почему это делается, и как избежать ошибок (а можно вообще не сообщать об ошибках). когда вы используете в VueTypeScript, вам нужно изучить, как заставить его распознавать тип компонента Vue, как делать автоматические подсказки и проверку типов. когда выajaxКогда вы его используете, вы обнаружите, что вам нужно изучить, как сопоставлять данные, возвращаемые сервером, с определенным типом (а затем обнаружите, что это бесполезно во время выполнения).
Front-end архитекторы также уделяют этому много внимания.
Это хороший статус-кво? Не обязательно, но статус-кво действительно имеет место Кто не является архитектором этого горшка?
V. Резюме
Так называемая архитектура, как я понимаю, заключается в комплексном рассмотрении цели, отрасли и команды, как разумного выбора решения, способного не только поддержать развитие бизнеса, но и удовлетворить команду. Если эта цель может быть достигнута, это, естественно, хорошая архитектура. В настоящее время фронтенду непросто добиться хорошей архитектуры, и он делает не меньше, чем бэкенд.
Что касается того, являются ли так называемые архитектурные вещи, сделанные фронтенд-архитекторами, высокими, это еще один вопрос без ответа.