Главная » Статьи » Front-of-the-front- и back-of-the-front-end веб-разработка

Front-of-the-front- и back-of-the-front-end веб-разработка

Front-of-the-front- и back-of-the-front-end веб-разработка

От автора: существует большая разница, и я рад, что термины front-of-the-front и back-of-the-front-end получили распространение с тех пор, как я пошутил о них на Shop Talk Show. Некоторые из моих клиентов фактически отошли от принципа «мы нанимаем только full-stack разработчиков» и вместо этого приняли термины front-of-the-front-end и back-of-the-front-end, чтобы помочь лучше организовать свои команды и улучшить методы найма.

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

Я кратко сформулировал разделение таким образом, чтоб front-of-the-front-end разработчик определял внешний вид кнопки, в то время, как back-of-the-front-end разработчик определял, что происходит при нажатии на нее.

Я писал о своем опыте работы в качестве front-of-the-front-end разработчика, но подумал, что было бы полезно создать отдельный пост, в котором излагались бы роли и обязанности и front-of-the-front-end и back-of-the-front-end разработчиков.

front-of-the-front-end разработчик

Определение: front-of-the-front-end — это веб-разработчик, который специализируется на написании кода HTML, CSS и представления JavaScript.

В его обязанности могут входить:

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

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

Создание JavaScript, который в основном управляет объектами в DOM, например, заставляет панель аккордеона открываться или закрываться при нажатии заголовка аккордеона или закрытии модального окна.

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

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

Работа с дизайнерами для обеспечения того, чтобы бренд, видение дизайна и лучшие практики UX были должным образом переведены в браузер, который, напоминаю вам, является тем местом, где реальные люди пойдут использовать реальный продукт.

Работа с разработчиками серверной части интерфейса для обеспечения совместимости кода интерфейса с внутренним кодом, службами, API-интерфейсами и другой технологической архитектурой.

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

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

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

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

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

Исторически разделение между «интерфейсом» и «сервером» было очевидным: разработчики внешнего интерфейса писали на HTML, CSS и JavaScript, а разработчики серверного интерфейса писали на PHP, Python, ASP.NET или других серверных приложениях. Но теперь, когда JavaScript набрал популярность, большая часть этого кода, который исторически был написан на другом языке, теперь написан на JavaScript, стирая границы как между front-of-the-front-end, так и back-of-the-front-end разработчиков, а также разработчиков back-of-the-front и традиционных back-end разработчиков. Так что стоит определить, что именно делает разработчик back-of-the-front.

back-of-the-front-end разработчики

Определение: back-of-the-front-end разработчик — это веб-разработчик, который специализируется на написании кода JavaScript, необходимого для правильной работы веб-приложения.

В их обязанности могут входить:

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

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

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

Оптимизация производительности кода JavaScript для создания быстрого, приложения, которое быстро принимамет и отправляет данные.

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

Создание архитектуры и управление инфраструктурой на основе JavaScript, например фреймворками, инструментами и службами Node.

Управление материалами DevOps, такими как сборщики JavaScript, инструменты развертывания, CI / CD и т. д.

Работа с разработчиками внешнего интерфейса для обеспечения того, чтобы библиотека компонентов пользовательского интерфейса содержала все компоненты, варианты и перехватчики API, необходимые для создания приложения и всех его состояний.

Работа с командой разработчиков для обеспечения точного представления всех состояний продукта в работающим приложении

Работа с другими разработчиками серверной части и ІТ-отделом для обеспечения наличия необходимой технической инфраструктуры и способности приложения правильно интегрировать / взаимодействовать с внутренним кодом, отличным от JavaScript.

Примечание. Я не являюсь таковым разработчиком, поэтому эти пункты могут быть неполными или не совсем точными. Не стесняйтесь предлагать и исправлять!

Некоторые соображения

Граница между front-of-the-end и back-of-front-end может быть нечеткой и сильно варьируется от разработчика к разработчику. Вполне возможно, что один разработчик сможет выполнять множество задач во всем спектре интерфейса. Но также стоит отметить, что это не очень распространено.

Эти роли и обязанности постоянно меняются, но общее разделение на “внешний вид” и “функционал” по-прежнему остается хорошо заметным.

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

Вот так! Это область, которой я давно увлекаюсь, поэтому я хотел бы услышать о вашем опыте. Вы разочарованный full-stack разработчик? Изменилась ли ваша организация в сторону разделения front-of-the-front-end/back-of-the-front-end?

Автор: Brad Frost

Источник: bradfrost.com

Редакция: Команда webformyself.