Ср. Дек 1st, 2021

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

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

Докладывает webformyself.com

от Admin

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *