Почему современный фронтенд такой плохой, и что с этим делать?

Дмитрий Карловский

Эксперт в области веб-разработки MPK Software

ИТ-сфера и веб-индустрия быстро развивались в последнее время: в 2023 году ИТ-рынок достиг 3,1 трлн рублей, а среднегодовой темп прироста составил 26%. В условиях быстрого роста сферы вчерашние джуны становились техническими директорами не потому, что были хорошими архитекторами или крутыми разработчиками, а потому что не было другой альтернативы — опытных разработчиков на все компании не хватало. 

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

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

Один из примеров — негативная реакция к пресс-релизу на «Хабр» о создании нового оптимизированного веб-интерфейса «Т-Банка» «на React» восемь лет назад. Тогда пользователи отметили трудности использования нового веб-интерфейса из-за низкой скорости его работы.  

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

И если спросить бизнес, что он выберет —  «быстро или качественно?» — то он зачастую ответит: «быстро, а потом оптимизируем». Это «потом», как правило, так никогда и не наступает. 

Да и вместо «быстро» получается «медленно и дорого». К тому же куда большая проблема подхода «на React» заключается в том, что разработка ведется вовсе не «на React», а на собственном уникальном фреймворке, стихийно собранном из сторонних библиотек сомнительного качества, только одной из которых является React. 

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

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

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

В качестве примера рассмотрим селекторы времени. Так, Apple предлагает пользователю вместо двух точных нажатий крутить барабан, вызывая «приятные ассоциации» с «одноруким бандитом» каждый раз, когда человек пролетает мимо нужного значения. А Google предлагает искать числа на круговом циферблате, но это единственное место, где современный человек его видит, тем более в 24-часовом исполнении. При этом выбранное время выводится именно в цифровой форме, а не стрелками на циферблате. 

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

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

Приведу пример — пять лет назад я разрабатывал редактор документов для новой платформы «1С». Когда нужно было показывать прогресс руководителю разработки, тот открывал проект на старом компьютере с Windows XP. Конечно все тормозило, но это давало мне толчок уделять больше внимания эффективности алгоритмов. И хоть идеальной отзывчивости на компьютере с Windows XP мне добиться так и не удалось, на более современных системах редактор документов работал отлично, даже со сложной версткой на 200 печатных страниц. 

Резюмируя, я рекомендую руководителям попробовать следующие практики для направления подчиненных в сторону улучшения продукта: 

• Требовать глубокий сравнительный анализ альтернатив по каждому техническому решению и привлекать к анализу широкий круг специалистов. 

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

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

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

  Вас может заинтересовать: 

  Эксперты выяснили, что дизайнеры не знают о правовых рисках применения ИИ