Что такое фронтенд-инжиниринг?

Хотя концепция фронтенд-инжиниринга не существует уже несколько лет, слово «инжиниринг» не является новым словом.В других областях разработки программного обеспечения уже давно существует высокий уровень инженерии, например, веб- сервера разработка. Просто в то время у фронтендеров не было инженерной грамотности, и не было необходимости выполнять инженерные операции на фронтенде. как «приложение» ко всему процессу разработки проекта. Так почему же в последние годы концепция фронтенд-инжиниринга вдруг стала горячей темой? Нелегко хорошо говорить о фронтенд-инжиниринге. Я начну со следующих аспектов и дам краткое объяснение концепции фронтенд-инжиниринга. Это только личное понимание. Надеюсь, вы будете общаться и обсуждать больше.

1. Почему передняя часть должна быть спроектирована?

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

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

2. Основа реализации front-end инжиниринга — разделение front-end и back-end

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

Эффективность совместной разработки в этом традиционном режиме очень низкая.Если ошибка обнаружена в тесте страницы, ошибка связана с пропущенной буквой в значении ClassName.Вы думаете, что это вина внешнего интерфейса? инженер,или это запоздалая мысль?А как же невнимательность конечного инженера,когда он задает шаблон? В конце концов, на веб-сайте тысячи DOM-узлов, и никто не может гарантировать, что ни одна строка кода не будет ошибочной. Если после запуска проекта обнаруживается, что существует отклонение в 1 пиксель между фактическими пикселями веб-страницы и черновиком дизайна, в это время фронтенд-инженеру необходимо изменить дизайн статической HTML-страницы, и затем передайте его бэкэнд инженеру, чтобы продолжить установку шаблона, и ждите, пока весь процесс пройдет.После этого вы найдете более серьезную проблему.Отклонение всего 1 пиксель во всем проекте. Можно мобилизовать всю команду разработчиков для решения этой проблемы с 1 пикселем, что сильно тратит ресурсы команды.

Вышеупомянутые проблемы являются лишь верхушкой айсберга в традиционных проблемах разработки.Столкнувшись с таким количеством проблем, возникла отдельная разработка фронтенда и бэкенда. Раздельная разработка front-end и back-end обеспечивает живую почву для развития front-end разработки. В связи с постоянными изменениями рыночного спроса фронтенд-разработка перешла от традиционной модели WebPage к модели WebApp, а изменения в форме веб-продуктов также постоянно приводили к изменениям в содержании работы фронтенд-инженеров. В ответ на различные «изменения» фронтенд-инженеры также должны разработать свои собственные «методологии» фронтенд-разработки.

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

3. Как внедрить фронтенд-инжиниринг?

Уточнение разделения труда между front-end и back-end разработкой — это первый шаг к реализации разделения front-end и back-end, а также основа для последующей реализации различных схем оптимизации front-end. Передние инженеры в основном отвечают за:

Обработка статических и динамических ресурсов;
JavaScript реализует интерфейсную бизнес-логику;
Вывод файлов шаблонов HTML;
Веб-сервисы среднего уровня, обычно реализуемые Node.js;
Фронтенд-юнит-тестирование;
Развертывание фронтенд-проекта;

Среди них к статическим ресурсам относятся файлы .js, файлы .css, изображения и медиафайлы различных форматов и т. д. Эти файлы не зависят от сервера и требуют только парсинга в браузере, динамические ресурсы относятся к HTML-шаблонам. Проект не является SPA (одностраничным) приложением, которое обрабатывается сервером, поэтому мы должны рассмотреть, как реализовать отрисовку HTML-шаблонов. Развертывание внешнего интерфейса относится к развертыванию файлов статических ресурсов на тестовом сервере и развертыванию файлов шаблонов HTML на сервере промежуточного уровня Node.js.

С точки зрения общего аспекта разработки проекта, реализация предварительного проектирования также требует владения следующими аспектами:

(1) Используйте Webpack для реализации построения проекта

Короче говоря, конструкция — это компиляция. Окончательное право собственности на все файлы разработки интерфейса передается браузеру для анализа, рендеринга и представления страницы пользователю. Конструкция заключается в преобразовании всего исходного кода в интерфейсе. завершить разработку в хост-браузер, который может быть выполнен. Есть только три файла ресурсов, созданных интерфейсной конструкцией, файлы HTML, CSS и JS. Вещи, которые должны быть скомпилированы:

JS-код, который не может быть напрямую распознан браузерами, включая ES6/7/8/9/10 и другие JS-коды, соответствующие спецификациям ECMAScript;
Код CSS, который не может быть напрямую распознан браузерами, включая предварительно скомпилированный синтаксис CSS, такой как SASS/LESS;
код HTML-шаблона, который не распознается браузерами, включая механизмы шаблонов Node.js, такие как jade, ejs, artTemplate и mustache;

Построение проекта на самом деле должно компенсировать дефекты и недостатки самого браузера, и это процесс компиляции, ориентированный на язык. Тогда, помимо самого языка, при построении фронтенда следует учитывать еще и оптимизацию производительности веб-приложений. Эти оптимизации в основном предназначены для сокращения HTTP-запросов и улучшения взаимодействия с пользователем, в том числе:

Упаковка зависимостей, которая упаковывает файлы зависимостей синхронизации вместе, чтобы уменьшить количество HTTP-запросов;
Встраивание ресурсов, например компиляция изображений размером менее 10 КБ во встроенные документы формата base64 для сокращения HTTP-запросов;
Сжатие файлов, уменьшение размера файла и сокращение времени запроса;
Добавляйте отпечатки хэшей в файлы для работы с политиками кэширования браузера;
Измените доменное имя и статический путь к файлу ресурсов в среде разработки до доменного имени и пути в производственной среде;
изменение имени файла;

Здесь нужно пояснить, что помимо Webpack в инструментах построения фронтенда есть и другие инструменты, такие как Gulp, Grunt и т. д. Почему здесь упоминается только Webpack? На самом деле Gulp и Grunt можно рассматривать только как инструменты управления рабочим процессом. Они сами по себе не предоставляют конкретных функций. Все функции, такие как создание и развертывание, должны выполняться соответствующими подключаемыми модулями. Использование Gulp и Grunt предназначено только для облегчения рабочий процесс каждого звена проекта контроль. Кроме того, тема и уровень использования этих двух инструментов намного меньше, чем у Webpack.Хотя Webpack — это инструмент для конструирования, который появился только в последние два года, он по-прежнему стал одним из самых популярных инструментов для конструирования. два front-end фреймворка Vue и React Loader также написаны официальным или самим автором. Поэтому, когда мы говорим о фронтенд-инжиниринге, мы рекомендуем использовать в качестве инструмента Webpack.

(2) Используйте Babel для завершения компиляции JavaScript

Можно сказать, что JavaScript является самым основным языком программирования во внешнем интерфейсе, который мы часто называем «JS». Сам JS может выполняться непосредственно в браузере, так зачем использовать Babel для его повторной компиляции? На самом деле, я хочу объяснить здесь, что после официального выпуска ECMAScript2015 (сокращенно ES6) внимание фронтенд-инженеров сместилось с «JS» на «ES». Как профессиональные фронтенд-инженеры, вы все должны знать что JavaScript ≠ ECMAScript.

ECMAScript — это стандарт, а JavaScript — это подмножество стандартной реализации ECMAScript. API хост-браузера (BOM и DOM) плюс JavaScript составляют JavaScript в нашем традиционном понимании. Однако при непрерывной итерации версий ECMAScript это не приносит удобства в разработке.Из-за отставания в реализации браузерной поддержки новой спецификации ECMAScript даже последний браузер Chrome не полностью поддерживает ECMAScript2015 (ES6).Все спецификации , и ECMAScript2017 был выпущен, чтобы новая спецификация ES могла лучше подключаться к браузеру, выделена роль Babel для компиляции синтаксиса JavaScript.

Роль Babel заключается в том, чтобы просто преобразовать синтаксис спецификации ECMAScript, который не реализован браузером, в работоспособный синтаксис низкой версии, например, преобразовать классы ES6 в реализации прототипа ES5.

(3) Прекомпиляция CSS

Как язык стилей, который браузеры могут напрямую распознавать, CSS компенсирует недостатки нативных стилей HTML.Для ранней разработки в Интернете требования к стилю несложны, и требуется лишь небольшой объем кода CSS. Тем не менее, в соответствии с текущей тенденцией достижения максимального пользовательского опыта требования к разработке CSS постоянно растут, и сложная разработка CSS стала очень громоздкой и болезненной. Основная причина по-прежнему ограничена реализацией браузера и слабой способностью программирования самого CSS.

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

(4) Модульная разработка

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

избегать конфликтов имен;
облегчить управление зависимостями;
Способствует оптимизации производительности;
улучшить ремонтопригодность;
улучшить возможность повторного использования кода;

До выпуска спецификации ES6 существовало три основных спецификации для модульной разработки интерфейса: CommonJS, AMD и CMD.

CommonJS — это статическая модульная спецификация, применимая только к JavaScript, подходящая для разработки Node.js, но не подходящая для среды браузера; в то время как спецификации AMD/CMD не полностью согласованы, но основные функции унифицированы, обе спецификации являются ключевыми. решить потребность браузера в модульности внешнего интерфейса.

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

(5) Компонентная разработка

Как упоминалось ранее, компонентизация и модульность — это две совершенно разные концепции: модульность — это разделение кода и ресурсов на уровне файлов, а компонентизация — это разделение пользовательского интерфейса на уровне дизайна. Структурная единица, отделенная от пользовательского интерфейса, становится компонентом пользовательского интерфейса.Единица компонента пользовательского интерфейса содержит шаблоны HTML, стили CSS и логику JS. В процессе проектирования страницы каждый элемент на странице является компонентом, и страница тоже является компонентом, но страница является большим компонентом, а затем этот большой компонент собирается из множества мелких и средних компонентов. Средние компоненты также могут быть разделены на мелкие компоненты, а мелкие компоненты могут быть разделены на элементы DOM.Элементы DOM также принадлежат собственным компонентам браузера и являются базовой единицей компонентов. Эта составная разработка является идеей фронтенд-разработки «разделяй и властвуй».

(6) Локальный сервер и фиктивный сервис среды разработки

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

Mock-сервис решает проблему совместной разработки front-end и back-end: Front-end и back-end разработчики заранее согласовывают спецификации, а front-end инженеры помогают в написании логики front-end и разработке функциональных модулей через интерфейс данных Mock. предоставляется локальным сервером. Если в проекте требуется отрисовка на стороне сервера (SSR), локальный сервер также должен иметь возможность анализировать HTML-шаблоны, а служба Mock предоставляет данные инициализации, необходимые для SSR.

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

(7) Ограничения нормализации

Будь то разработка на стороне сервера или разработка переднего плана, стандартизированные ограничения имеют решающее значение. При разработке общей архитектуры проекта, чтобы принять во внимание такие факторы, как масштабируемость проекта, ремонтопригодность и высокая связность, разработчики будут инкапсулировать код и использовать операции конфигурации, чтобы упростить разработку проекта.Требуется парадигма программирования бизнес-кода. соблюдать установленные ограничения. Хотя это ограничение обеспечивает удобство разработки, оно в определенной степени ограничивает переносимость кода. Например, в проекте используется определенный инструмент сборки для решения требований проекта, но если однажды в проекте потребуется заменить другой инструмент сборки, конфигурация исходного инструмента сборки в коде станет избыточным кодом, и нет гарантия того, что такая конфигурация не будет конфликтовать с новыми инструментами сборки. Даже если конфликта нет, оптимизация производительности кода будет иметь определенное негативное влияние. Как услуга инженерное решение должно минимизировать негативное влияние на проект. Это наиболее важное соображение при формулировании спецификации ограничения парадигмы программирования.

(8) Оптимизированное развертывание проекта

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

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

4. Каково будущее развитие фронтенд-инжиниринга?

В настоящее время режим разделения труда при разработке веб-приложений все еще находится в исследовательском периоде, и из-за недавней тенденции «большого интерфейса» разработка фронтенд-инженеров может прорваться через веб-поле и развиться до мульти- конечные поля, такие как React Native, Weex, Electron, небольшие программы и т. д. С момента рождения «Cut Tuzi» до концепции большого фронтенда позиционирование и технический объем фронтенд-инженеров менялись, но сервисные объекты, производимые фронтенд-инженерами, всегда являются пользователями. До Node.js браузер был «одним акром земли» для выживания фронтенд-инженеров.Появление Node.js сломало эту ситуацию, что привело к тенденции развития «большого фронтенда».

Средний уровень Node.js + браузер — это основной режим для реализации «большого внешнего интерфейса» в настоящее время. Разработчики внешнего интерфейса имеют все ресурсы, связанные с пользователями, и могут полностью понять ход разработки и реализовать более разумный внешний интерфейс и схема разделения задней части. Эта модель позволяет фронтенд-инженерам преодолеть узкое место браузеров и перейти на уровень веб-приложений, что также является основной тенденцией фронтенд-разработки в будущем.

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

Положение фронтенд-инженеров неизбежно изменится в будущем, но единственный постоянный принцип фронтенд-инжиниринга — всегда фокусироваться на фронтенд-разработке.Фронтенд-инжиниринг не имеет единого отраслевого стандарта, фиксированной формы и Наиболее разумное решение Пока позиционирование фронтенд-инженеров все еще меняется, процесс фронтенд-инжиниринга будет продолжаться.