У программистов GUI есть неоправданное преимущество перед другими?


23

Менеджеры и клиенты могут легко оценить то, что они могут видеть.

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

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

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

РЕДАКТИРОВАТЬ : я должен объяснить здесь, что под программистом GUI, я имею в виду не полноценный веб-дизайнер / дизайнер GUI, а программистом переднего плана, например, программист java-swing.

Согласна ли остальная часть сообщества?


6
Кто должен страдать от «глупых» запросов пользователей на шрифты, метки, цвета и все вокруг? Ты берешь хорошее с плохим.
JeffO

@ Джефф О: Очень верно. Ни один пользователь никогда не критиковал мой выбор того, сколько памяти выделять для структуры данных или какие столбцы таблицы базы данных индексировать.
dan04

2
Необходимость работать с макетами (будь то Swing, GWT, HTML, CSS.) - это такая пытка, что отсутствие необходимости работать с ней является преимуществом ...
Ури

@ dan04: попробуйте работать со старшими научными пользователями. Они счастливы использовать уродливые пользовательские интерфейсы и потратят целую вечность, борясь за структуры баз данных (обычно в попытке сохранить какую-то старую нерасширяемую бессмысленность, потому что их используют старые сценарии). Grr…
Донал Феллоуз

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

Ответы:


21

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

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

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

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

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


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

1
+1. Я работаю над графическим интерфейсом, и всякий раз, когда возникает «проблема», он попадает в мой почтовый ящик. Тогда на мне лежит обязанность «доказать», что источник проблемы исходит из низов. Программисты GUI также должны совмещать «чистоту» этих прекрасных API с хаосом пользовательских требований.
Бенджол

10

Для человека, который не имеет никакого отношения к программистам, я могу с уверенностью сказать, что они поверили бы в подобные вещи. Они не знают объем работы, выполняемой в фоновом режиме, все, что они видят, - это набор кнопок / текстовых полей / меню / [вставить элемент GUI] и скорость, с которой выполняется начальная кнопка. Поэтому изначально люди с графическим интерфейсом понравились больше.

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

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


Одним словом, это зависит от человека и от того, что ты делаешь.


8
Как человек, который только что провел последние 5 лет или около того, работая над инфраструктурой (стеки SIP), +1 - большинство людей не знают, что вы делаете, и нет ничего особенно заметного, кроме того, что что-то не работает. Как много вы думаете о вашей сантехнике ... пока она не сломается?
Фрэнк Шиарар

6

Как «эксперт по пользовательскому интерфейсу» в моей компании (парень, отвечающий за всю разработку пользовательского интерфейса, а не только за дизайн), я думаю, что вы можете упустить какую-то часть истории. Хотя я отвечаю за пользовательский интерфейс, я также работаю над бэк-эндом, над базами данных и т. Д. Я делаю все это (мы небольшая команда). [C # и разработка ASP.Net WebForms]

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

Во-вторых, разработка внешнего интерфейса была для меня гораздо более сложной, чем когда-либо прежде (непонятные / сложные алгоритмы в стороне). Есть еще много вещей, от которых нужно защититься, это отсутствие состояния (наши приложения находятся в Интернете), браузеры не ведут себя согласованно (библиотеки JavaScript были хорошей находкой) и т. Д. Я надеюсь, что большая часть этой сложности связана с моей структурой работать с (ASP.Net WebForms) и что все сложные вещи не будут проблемой в будущем.

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


5

Я ненавижу разработку GUI по двум причинам,

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

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


4

Чтобы (возможно) немного расширить ответ @ TheLQ, я думаю, что это также зависит от "зрителя".

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

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

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

РЕДАКТИРОВАТЬ: Я мог бы добавить, что, будучи человеком, который чувствует себя более комфортно, работая над предметами более низкого уровня, я был измучен, когда вы работали так же усердно, как и команда UI, и это демо, которое хвалили в демоверсии, а не тот факт, что система " просто работал ". Но, как я уже сказал, я знаю, что мой руководитель знает, что работа необходима во всех областях.


3

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

Тем не менее, я думаю, что пользовательский интерфейс намного сложнее, чем любая другая часть наших приложений. И я не говорю о дизайне UX, я говорю о кодировании. Сколько других областей мы кодируем, где мы должны учитывать десятки, если не сотни, или возможные сценарии? Изменение размера экрана иногда может стать королевской болью, когда вам нужно выяснить, что должно произойти с парой дюжин элементов. Это в первую очередь возникает, когда у вас есть рекомендации, в которых говорится: «нам нужно поддерживать 800x600», а затем разработчики UX, которые никогда не используют ничего, кроме разрешения HD.

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


3

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

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

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


2

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

Когда ваш менеджер спросит вас, что вы сделали за последний месяц, легко показать крутой графический интерфейс. Трудно показать крутой API. Очень тяжело. Прохлада API проявляется только при реальном использовании - ее невозможно оценить с первого взгляда.


1

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


1

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


1

Это зависит от аудитории. Я работаю со многими финансовыми аналитиками, и их идея хорошего дизайна графического интерфейса включает в себя столько областей, сколько вы можете вставить в одну форму. Серьезно, я говорю 75 - 100. Они наркоманы данных, которые всегда хотят большего. Недавно я улучшил производительность нескольких хранимых процедур, загрузка которых могла занять 45 секунд (рассчитать средневзвешенные значения с начала времени). Получил до 30 секунд; Я думаю, вау, сократить треть времени; это должна быть позиция в моем резюме. Никто даже не заметил. Продолжал работать над этим и получил это к 15-20. Заметное изменение. Все были очень счастливы. Я все еще думаю, что графический интерфейс - мерзость, и если бы мы убрали эту бесполезную чушь, она загрузилась бы через 2 секунды,

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


1

Тестирование UI частей приложения - это кошмар.

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

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

Но если какая-либо ошибка будет замечена ( некоторые всегда случаются), первым, кто будет осужден, будет программист GUI. Пользователь просто никогда не видел других!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.