Глубокое погружение в основные болевые точки веб-разработчиков

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

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

Испытание 1 квартал 2021 г. 2 квартал 2021 г. 3 квартал 2021 г. 4 квартал 2021 г.
Отслеживание изменений в веб-платформе или веб-стандартах. 27% 26% 27% 22%
Идти в ногу с большим количеством новых и существующих инструментов или фреймворков. 26% 26% 25% 21%
Сделать дизайн или взаимодействие одинаковым во всех браузерах. 26% 28% 24% 21%
Тестирование в браузерах. 23% 24% 20% 20%
Понимание и реализация мер безопасности. 23% 25% 20% 19%

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

Обсуждения разработчиков

Отказ от ответственности: эти идеи основаны на небольшом количестве разговоров с разработчиками. Когда вы используете «все» или «некоторые», это относится к опрошенным разработчикам, а не ко всему сообществу. Для более широкой экстраполяции этих выводов необходимы дополнительные исследования.

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

Одной из общих черт всех разработчиков является то, что все они используют CMS или фреймворк для выполнения своей работы. Были упомянуты Wordpress, React, Bootstrap, Angular и Tailwind, ни один из разработчиков не использовал в производстве ванильную веб-платформу. Выбор фреймворка при запуске проекта — непростая задача, и разработчики часто учитывают нетехнические требования. Например, легко ли будет нанять разработчика для работы с этим фреймворком. Мы не сможем улучшить болевые точки разработчиков, если в решение не включены фреймворки и CMS.

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

Другая область неопределенности – это определение веб-стандартов . Когда их спросили о примерах соблюдения стандартов, многие разработчики вместо этого указали на трудности с соблюдением лучших практик. Это еще одна область, которую нам необходимо прояснить в ходе опроса.

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

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

Большинство разработчиков согласны с тем, что совместимость — одна из самых больших проблем. Ситуация улучшается благодаря таким усилиям, как Compat 2021 и Interop 2022 , но ясно, что разработчики пока не считают это решенной проблемой.

Большинство разработчиков так или иначе используют полифилы. Однако во многих случаях использование прозрачно для разработчиков, поскольку полифилл может быть автоматически добавлен с помощью такого инструмента, как Babel, или фреймворка. Для тех, кто самостоятельно управляет своими полифилами, выяснение того, является ли полифил «хорошим», может стать проблемой. В качестве сигналов разработчики упомянули использование количества установок на NPM и создателя полифила. Несколько разработчиков упомянули о работе по удалению полифилов, которые стали ненужными из-за прекращения поддержки IE 11.

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

Заключение

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

Интересно, есть ли способ внести разработчикам больше ясности в то, как все взаимосвязано, и добиться большей согласованности между всеми частями, не ставя под угрозу разнообразие. Это большая и сложная проблема, и ее трудно решить сразу. Но с чего вообще начать?

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