События сегодня

Инженеры-бэкенд-программисты тоже являются дизайнерами

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

Интернет переполнен мемы «разработчик против дизайнера», и нельзя отрицать, что такое сотрудничество может дать как впечатляющие, так и веселые результаты. «Дизайнер» — это термин, который мы часто (а иногда исключительно) ассоциируем с ролями, связанными с «дизайном интерфейсов», такими как веб-дизайнер, дизайнер UI/UX, дизайнер продуктов и т. д. Возможно, даже подсознательно, мы связываем его с кем-то артистичным, творческим и с упором на создание красивых и интуитивно понятных продуктов с тщательно продуманной эстетикой.

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

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

Хотя их часто противопоставляют друг другу в веселых мемах, на самом деле они более похожи, чем думают люди.



Инженеры-бэкенд-программисты тоже являются дизайнерами

Пост Энди Белла на x (Twitter)

Прагматическая сторона дизайна

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

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

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

  • Определение архитектуры системы
  • Добавление новых микросервисов
  • Привлечение нового SaaS-провайдера
  • Изменение API
  • Редактирование структуры данных

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

Мастерство серверных инженеров

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

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

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

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

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

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

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

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

Информация для Вас была полезна?
0
0
0
0
0
0
0

Похожие статьи

Кнопка «Наверх»