Почему некоторые программисты ненавидят часть разработки пользовательского интерфейса? [закрыто]

Многие программисты, которых я встречал, всегда говорят, что «он не парень с интерфейсом». Дело в том, что в настоящее время разработка, будь то веб, Windows, Linux, OSX или любой другой тип разработки, теперь включает в себя программное обеспечение с красивым пользовательским интерфейсом. Почему многим разработчикам не нравится работа интерфейса?

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

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

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

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

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

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

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

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

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

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

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

Лично мне не нравится разработка пользовательского интерфейса, потому что я не очень хорош в этом. Существует ОГРОМНЫЙ элемент пользовательской психологии, который я не очень хорошо понимаю. Я думаю, что моя самая большая проблема в том, что я не могу поставить себя на место пользователя. Я не знаю, как создавать интуитивно понятные макеты, потому что я не знаю, что интуитивно понятно для пользователя, и при этом я не знаю, как сделать вещи красивыми.

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

Проблема с дизайном пользовательского интерфейса в том, что у всех есть мнение ... И нет правильного или неправильного ответа. С другой стороны, разработчики любят черно-белое и логику. В компании любого размера все с этим согласятся 1+1=2, но спросите, какой шрифт облегчает чтение (Comic Sans Obviously)... будьте готовы к потопу. Десять тысяч разных ответов, и все правы, потому что все разные.

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

Разработка требует умения хранить много данных в уме и иметь дело со многими одновременно. Дизайн пользовательского интерфейса требует возможности сводить его как можно меньше к минимуму, не жертвуя его целостностью. Я люблю вызов этого; и я съеживаюсь, когда вижу, что кто-то создает пользовательский интерфейс, который представляет собой неуправляемые данные на экране. (Я также абсолютный фанат, когда дело доходит до макета, теории цвета и т. Д.)

С другой стороны, я ненавижу вещи низкого уровня. Я никогда не буду касаться кода для драйверов, ядер или чего-то подобного: shudder: Я оставлю это «парням без пользовательского интерфейса», и я рад, что кому-то еще нравится это делать, иначе это никогда не будет сделано.

Я думаю, это зависит от того, использует ли большинство программистов левую часть своего мозга.

Хороший источник для дальнейшего чтения этой темы.

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

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

Вы не можете сделать это. Я сидел на собрании, где два верхних сотрудника бухгалтерии (ок. 500 тыс. В год) в крупной юридической фирме полчаса спорили по поводу ярлыка на странице для выставления счетов, которую использовали адвокаты. Предполагалось, что это поможет юристам понять. Почему бы просто не спросить адвокатов? Слишком легко. Таким образом, ИТ-отдел получает 50 телефонных звонков от юристов, желающих узнать WTF «Остаточная чистая сумма счета» и почему она указана в форме ввода времени.

Некоторые люди любят брокколи, некоторые нет. Возможно, нам придется есть это, но нам это не должно нравиться, и мы не собираемся наслаждаться этим, когда мы его едим. Мало того, мы избежим того, чтобы съесть это столько, сколько мы можем.

Есть много других вещей, которые можно кодировать, кроме только пользовательского интерфейса. Встраиваемые веб-службы, службы Windows (не так уж много пользовательского интерфейса в микроволновой печи) - это лишь несколько примеров.

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

В разработке пользовательского интерфейса есть определенные вещи, которые трудно понять правильно.

Макет является одним из них. Я создаю пользовательский интерфейс более 15 лет и до сих пор не нашел достойного решения для управления макетом.

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

Я знаю, что раньше я ненавидел UI dev, потому что это было очень утомительно и медленно, особенно написание кода макета для позиционирования вещей в форме или в winow. Теперь с инструментами дизайнера пользовательского интерфейса, такими как Forms Designer в Visual Studio, мне это почти нравится . Другие причины ненавидеть это, я слышал от других, включали «это глупо», «это всегда слишком сильно меняется», «это не достаточно сложно», «это утомительно / скучно».

Почему не всем шахматистам нравится создавать шахматные доски и фигуры, с которыми они играют?

Это не странно, что некоторым людям это не нравится ... странно, что вы ожидаете, что мы должны.

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

Я не столько ненавижу работу пользовательского интерфейса, сколько ненавижу некоторые фреймворки пользовательского интерфейса. Например, я программирую на .NET более 10 лет. Фреймворки для создания веб-приложений великолепны (ASP.NET WebForms и ASP.NET MVC). Но фреймворки для написания настольных приложений, ну, я их не люблю (WinForms и WPF).

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

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

Например, приложение получает информацию через серию объектов DTO. Затем приложение создает свое собственное модельное представление данных (без повторного использования тех же классов домена, которые были созданы на сервере). Классы модели используются моделью представления (в шаблоне WPF MVVM), которая предоставляет свойства модели.

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

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

Я не большой поклонник разработки пользовательского интерфейса по следующим причинам:

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

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

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

Я делаю как пользовательский интерфейс (рабочий стол, а не веб) и внутренние кишки.

Количество, которое мне нравится или не нравится, зависит от того, сколько я могу сделать, используя что-то вроде предметно-ориентированного языка (DSL).

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

В области, не связанной с пользовательским интерфейсом, я извлек урок из ряда продуктов, которые начинались как DSL, которые можно использовать из командной строки, и к которым впоследствии был добавлен пользовательский интерфейс. Это дает опытному пользователю что-то, где он может обойти пользовательский интерфейс, а обычному пользователю - то, что он может использовать случайно. (Примеры: R, SPlus, Matlab, SAS, WinBugs.) Таким образом, наш продукт имеет язык командной строки для экспертов. Я люблю разрабатывать такие вещи с помощью парсера, генератора кода, прекомпилятора и механизма моделирования во время выполнения. Усилие, затраченное на это, по меньшей мере, в 10 раз меньше, чем на пользовательский интерфейс.

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

Итак, ваш вопрос был «Почему некоторые программисты ненавидят часть разработки пользовательского интерфейса?». Я ненавижу это только из-за того «клея», для которого у меня нет DSL.

Честно говоря, я считаю, что найти лучший GUI-инструментарий, а затем изучить все тонкости этого - это PITA ... не говоря уже о том, что вы не изучаете много UI в колледже, и я новичок, так что ...... ..

Помимо того, что уже было сказано (это утомительная, скучная, разочаровывающая работа по ее кодированию, и дизайн обычно выполняется заранее кем-то, кто не имеет ни малейшего представления о том, какие проблемы его идеи вызывают у тех, кто пытается их реализовать), важным фактором является то, что вы Вам приходится работать с людьми, чьи представления о том, что вы должны делать, постоянно меняются, гораздо больше, чем у бэкэнда. В результате вы стреляете по движущейся спецификации еще больше, и эти люди, как правило, тоже придирчивы. У меня буквально были неудачные тесты пользовательских интерфейсов, потому что компоненты находились в 1 пикселе от места, которое, по мнению тестируемого, должно было быть. Это сработало? Да. Выглядело ли это хорошо? Да. Но он начал считать пиксели, и что-то было не так, как остальные пиксели, поэтому он отправил его на доработку.

Еще несколько моментов:

1) Дизайн пользовательского интерфейса может быть сложнее проверить, конечно, вы можете проверить, выполняет ли эта кнопка то, что нужно, но проверить, сложнее ли ее использовать. Как насчет тестирования, если его можно будет использовать с человеком с ограниченными возможностями?

2) Многие программисты не обучены этому и не знают об этом много.

Дело в том, что многие инструменты / фреймворки / API пользовательского интерфейса плохи, сложны, далеко не интуитивно понятны. Я разрабатывал с Win32 API на C / C ++, с javax.swing, CSS и т. Д. С тех пор я ненавижу заниматься разработкой пользовательского интерфейса ... До фреймворка Qt!

Будучи студентом CS, вас научат структуре данных, базе данных, C ++ ... кроме пользовательского интерфейса. Таким образом, вы не будете в этом хороши с самого начала . Если вы не очень хороши в этом, вы будете ненавидеть это.

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

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

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