Разница в рабочей среде между фронтенд- и бэкенд-разработчиками зависит от размера организации. В средних и крупных организациях есть выделенные бэкенд-разработчики, а также выделенные фронтенд-разработчики. За последние три года с взрывом NodeJS и изоморфного/универсального JavaScript люди, которые изначально были фронтенд-разработчиками, создают больше бизнес-логики. Точно так же концепции, которые чаще встречались на серверной части, применяются к интерфейсной части в стиле WebWorkers, настоящих асинхронных функций, «классов» и баз данных на стороне клиента. В результате большая часть обязанностей фронтенд- и бэкэнд-разработчика смешивается с методологией полного стека. Однако мировоззрение этих традиционно обособленных дисциплин все еще укоренилось по-старому.

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

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

Авария под любым другим именем пахла бы так грязно

В серверной части «сбой» обычно означает, что произошла ошибка времени выполнения. Если есть какой-то процесс-оболочка, общий запрос вернет ошибку, и процесс автоматически перезапустится для обработки дополнительных запросов. С точки зрения восстановления, у потребителя (внешнего интерфейса) нет никаких шансов, и мы должны передать этот сбой дальше по стеку. Однако термин «авария» настолько широко используется в области бэкенда, что он плохо переводится во фронтенд-среду. Среда интерфейса связана с выполнением в браузере, который отвечает за синтаксический анализ разметки, стилей и сценариев по сгенерированному дереву (DOM). Для конечного пользователя, что-то, что работает не так, как ожидалось, считается «сбоем», но для разработчика нам нужно быть более подробными в нашей базовой терминологии. В таксономии ошибок применительно к внешнему интерфейсу:

а. Выполненный JavaScript блокирует выполнение, чтобы предотвратить взаимодействие с пользователем

Браузер выполнил некоторый JavaScript (наш или из библиотеки), который быстро превысил выделенный ЦП, так что другие внутренние задачи, такие как поддержание состояния глобального события, заставили браузер работать медленно с точки зрения пользователя. Иногда за этим следует диалоговое окно системного уровня, указывающее, что выполнение сценария занимает много времени. Это не настоящая катастрофа.

б. Перерисовка элементов приводит к блокировке выполнения для предотвращения взаимодействия с пользователем

Когда браузер узнает о новых элементах, созданных или уничтоженных в DOM, он должен отобразить их на основе сложных наборов правил. Если браузер не может применить эти новые элементы достаточно быстро, отрисовка новых элементов может замедлить работу браузера. Это само по себе не крах. Однако в приложениях WebGL в браузере существует логика, которая может привести к реальному сбою. Это сообщение «Oh Rats» в Chrome. На данный момент DOM полностью уничтожен, и пользователь должен обновить свой браузер.

в. Ошибка выполнения («ошибка консоли»)

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

Вы можете сказать, что «все остальное является ошибкой времени выполнения», но есть некоторые типы ошибок, которые не влияют ни на производительность, ни на ошибки времени выполнения. Однако они вызовут неожиданное поведение пользователя.

д. Ошибка привязки события

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

e. Ошибки стиля

Страница становится пустой. Вы не можете ни на что нажимать. Для чисто внутреннего разработчика без понимания среды браузера это «крах». Для пользователя сайт сломан, и мы сразу нажмем «назад». Для фронтенд-разработчика мы не видим никаких ошибок времени выполнения и видим, что DOM загрузился, но ничего не отображается. Хотя это крайний случай, мы должны понимать, что отсутствие рендеринга компонента пользовательского интерфейса не является сбоем.

ж. Настоящий сбой

Я определяю «настоящий сбой» как тот, который вызывает сообщение «О, Snap» в Chrome. Что-то пошло настолько плохо, что процесс браузера, ответственный за рендеринг содержимого этой вкладки, не смог продолжить его обработку. Они часто возникают из-за плагинов, неконтролируемых бесконечных циклов и чрезмерного использования памяти.

«Обработка — это провокация — это заводит людей!»

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

Здесь я считаю, что интерфейс — это лишь малая часть того, на чем в основном сосредоточена внутренняя разработка. У нас есть WebWorkers, AMD/Webpack/Browserify, и большинство современных сайтов следуют передовым методам разделения представлений и моделей и постепенно загружают наборы данных. Сайты, которые используют разработку на основе метрик для повышения производительности страницы, особенно на мобильных устройствах, получат огромные преимущества от оптимизации своего внешнего интерфейса. Все чаще не только простые приложения становятся мобильными, но и приложения, интенсивно использующие данные. Если для построения графика на мобильном устройстве требуется 5 секунд, нам нужно переосмыслить то, как происходит наша обработка и рендеринг.

Вместе мы инструмент, разделенный мы журнал

Я считаю, что чем больше инструментальная среда конкретного языка, тем больше у него шансов на успех. Google знает это, вкладывая значительные средства в инструменты разработчика для JavaScript. Эрик Эллиот написал отличную статью о постоянно улучшающейся экосистеме веб-инструментов. Я думаю, это показывает, что JavaScript на данный момент имеет огромный потенциал, несмотря на то, что некоторые утверждают, что экосистема инструментов стала перенаселенной. Перефразируя из какого-то источника, который я не могу найти в жизни, чем больше экосистема инструментов, тем выше скорость принятия базового языка. Среды внутренних инструментов для старых языков в основном остались прежними, но таким языкам, как Python, Go и NodeJS, теперь уделяется много внимания в том, как отлаживают и (интеллектуально) регистрируют живые процессы. Такие сервисы, как BugSnag, Errorception и Sentry, действительно блестят на этом фронте.

Объедините своих разработчиков, объедините свой разум

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