Есть ли у программистов GUI чрезмерное преимущество перед другими?
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Менеджерам и клиентам легко оценить то, что они могут увидеть.
Я видел много разработчиков графического интерфейса, которые являются средними программистами с минимальными знаниями принципов дизайна или других программирования. Тем не менее, эти недостатки часто остаются незамеченными, особенно руководством и клиентами, если программист может создать впечатляющий пользовательский интерфейс. Настолько, что многие разработчики графического интерфейса, которых я знаю, часами украшают графический интерфейс за счет плохого, незаметного кода.
С другой стороны, программисты среднего уровня, которые разрабатывают API или бизнес -функциональность или код базы данных (SQL и т. Д.), находятся в невыгодном положении, так как в демонстрации нет ничего осязаемого. Возможно, рецензент кода или архитектор может оценить элегантность, хороший дизайн, масштабируемость и т. Д. Кодекса, но это ничего не значит для внешнего мира. Ваш код может работать в течение многих лет, не ломая, может быть очень легко поддерживать и иметь хорошую производительность, но он никогда не вызывает «вау», который делает гладкий графический интерфейс.
По моему мнению, следствие этого (я знаю, и я буду в значительной степени понижены для этого, я знаю), что программист для программиста с графическим интерфейсом пишет хороший чистый код.
РЕДАКТИРОВАТЬ: Я должен объяснить здесь, что Gui Programmer, я имею в виду не полноценного дизайнера Web/GUI, а программист фронт-эн, например, программист с джавой.
Согласны ли остальная часть сообщества?
Решение
Я думаю, что вижу вашу точку зрения, но я подозреваю, что есть также противоположная проблема.
По сути, я считаю, что вы предполагаете, что, поскольку пользовательский интерфейс является элементом приложения «перед лицом» конечных пользователей, разработчики пользовательского интерфейса пользуются более высокой видимостью, чем члены команды, работающие в более глубоких слоях приложения.
Конечно, я согласен, что может быть более высокая видимость. Например, разработчики, работающие над элементами пользовательского интерфейса, могут чаще взаимодействовать с конечными пользователями (возможно, по веским причинам, поскольку они сосредоточены на аспекте взаимодействия человека и компьютера).
Тем не менее, я думаю, что более высокая видимость появляется даже в тех случаях, когда есть проблема. Например, конечные пользователи, скорее всего, сообщают о проблемах как «проблемы с графическим интерфейсом», даже если они нет.
Все это может сводить к восприятию, и зрелая организация должна иметь возможность распознавать ценности, добродетели и слабые стороны различных членов команды, независимо от какого уровня приложения, над которым они работают. Зрелая организация, возможно, также вышла за рамки различий, таких как «разработчик пользовательского интерфейса» и «разработчик бизнес -уровня», признавая, что все они все члены команды, возможно, с различными знаниями, но всегда пытаются обучать друг друга об этих областях опыта.
Другие советы
Для человека, который не имеет никакого отношения к программистам, я могу с уверенностью сказать, что он поверит в такие вещи. Они не знают, какой объем работы, которая идет в фоновом режиме, все, что они видят, - это куча кнопок/текстовых поток/меню/[Вставьте элемент графического интерфейса] и скорость, необходимая для достижения того, что началась кнопка. Итак, изначально людям по графическим интерфейсам нравятся больше.
Если человек делает Получите дело с программистами, тогда это немного по -другому. Как вы сказали, они заметят, если вы сделаете его масштабируемым, легче поддерживать, переписали алгоритм, чтобы это имело больше смысла или любую другую задачу типа обслуживания. Этот вид человека будет смотреть на всех программистов одинаково.
В середине это зависит от того, что вы делаете. Скорость тогда становится важным фактором здесь. Если вы можете показать до и после записей о том, сколько времени требуется для обработки и сохранения формы, и есть улучшение, вы равны. Если вы можете показать приложение под загрузкой от 100 клиентов и показать им таяние сервера, а затем покажите им свою версию, где все в порядке, ваша равная. И т.п.
Короче говоря, это зависит от человека и того, что вы делаете.
Как «эксперт по пользовательскому интерфейсу» в моей компании (парень, отвечающий за всю разработку пользовательского интерфейса, а не только дизайн), я думаю, что вы, возможно, упустите какую -то часть истории. В то время как я парень, отвечающий за пользовательский интерфейс, я также работаю на заднем плане, в базах данных и т. Д. Я делаю все это (мы маленькая команда). [C# и ASP.NET Webforms Development
Прежде всего, да, нетехническим людям гораздо проще оценить работу разработчика графического интерфейса, потому что это то, что связано с людьми. Для нетехнических людей, GUI - это приложение. Анкет Недостатком в том, что графический интерфейс также является первым, которого обвиняют, когда что -то пойдет не так.
Во-вторых, развитие фронтального конца было для меня гораздо более сложной задачей, чем когда-либо, за исключением задняя часть (неясные/сложные алгоритмы). Больше всего стоит защитить, это без гражданства (наши приложения находятся в Интернете), браузеры не ведут себя последовательно (библиотеки JavaScript были находкой) и т. Д. Я надеюсь, что большая часть этой сложности связана с структурой, которую у меня есть Работать с (asp.net webforms) и что все сложные вещи не будут проблемой в будущем.
В целом, у меня было гораздо больше сложности решать проблемы пользовательского интерфейса, чем проблемы со средыми.
Я ненавижу развитие графического интерфейса по двум причинам,
- Я более логичен, чем графически художественный, и мой пользовательский интерфейс всегда страдает в результате.
- Поскольку пользовательский интерфейс не основан на логике, модульные тесты почти невозможно написать с каким -либо значением
В конце концов, однако, я думаю, что мой код будет лучше оценен конечным пользователю (в отличие от спонсора проекта), чем кода посредственного разработчика, который находится в пользовательском интерфейсе, так как обычно работает Анкет
Чтобы (возможно) немного расширить ответ @Thelq, я думаю, что это также зависит от «зрителя».
У меня был некоторый опыт работы с несколькими менеджерами/руководителями высшего уровня, у которых нет опыта программирования. Некоторые ценят, что они не программируют, но понимают, что Chrome и Hubcaps так же важны, как и двигатель и шасси.
И у меня был опыт работы с некоторыми менеджерами/руководителями высшего уровня, которые не заботятся о каких -либо показателях, кроме ширины пользовательского интерфейса. Даже заявив, что больше разработчиков, ориентированных на пользовательский интерфейс, где важно.
ИМХО, мы все знаем, что вы не можете полировать какашку, и быстрое, надежное, но уродливое приложение будет намного хуже, чем приложение, которое выглядит хорошо и функционирует хорошо. Это все в глазах смотрящего, и, в какой -то степени, у вас есть сила (независимо от того, что вы делаете), чтобы вас видели в том свете, который вы хотите, работая на тех, кто ценит те же качества, что и вы.
РЕДАКТИРОВАТЬ: Я мог бы добавить, будучи тем, кто чувствует себя более комфортно, работая над предметами более низкого уровня, я был измучен, когда вы работаете одинаково так же усердно, как команда пользовательского интерфейса, и это лак, который хвалит в демонстрации, а не тот факт, что система » Просто работал ». Но, как я уже сказал, я знаю, что мой руководитель знает, что работа необходима во всех областях.
Я думаю, что существует общая презумпция, что разработчики пользовательского интерфейса являются «младшими» разработчиками. Я могу вспомнить только один случай, с которым я столкнулся с тем, где парень пользовательского интерфейса считался старшим.
Тем не менее, я думаю, что пользовательский интерфейс намного сложнее, чем любая другая часть наших приложений. И я не говорю о дизайне UX, я говорю о кодировании. Сколько других областей мы кодируем, где мы должны учитывать десятки, если не сотни или возможные сценарии? Просто изменение размера экрана иногда может стать королевской болью, когда вам нужно выяснить, что должно произойти с парой дюжины элементов. Это в первую очередь появляется, когда у вас есть руководящие принципы, в которых говорится: «Нам нужно поддерживать 800x600», а затем дизайнеров UX, которые никогда не используют ничего, кроме разрешений HD.
Так что, если они получают больше добра из -за большей экспозиции, они, вероятно, заслуживают этого. Обычно они неверно получают конец чаще, чем хороший прием.
Часто кажется идеей, что программист GUI находится в нижней части цепи программистов. Насколько сложно перетаскивать и отбросить кнопку в VS в форму? Что, вам потребуется неделя, чтобы программировать это? Это рисует несколько баров. Поэтому я не удивлен, увидев идею о том, что программисты с графическим интерфейсом, будучи такими, как они есть кнопки, должны писать ужасный код.
Программирование GUI имеет некоторые уникальные проблемы. Многопользовательская чтения, чтобы сохранить графический интерфейс активным во время загрузки данных. Это приводит к безопасному и правильному коду. Производительность очень важна. Никто не любит ждать две минуты, пока они снова не получит контроль над приложением. Способность повторного использования также становится большой проблемой. Если вам нужно написать десять аналогичных экранов, вы лучше структурируете свой код. Это приводит к лучшему коду. И, конечно же, создание хорошего графического интерфейса - сама по себе вызов.
Но для некоторых людей это будет просто перетаскивать кнопку в ваше приложение. Как и для некоторых людей, бизнес -логика - не более чем «проанализировать сообщение и поместить его в БД».
Я думаю, что это очевидно, что они делают. Возможно, первоклассные Dev Houses освобождены, но большинство других нет.
Когда ваш менеджер спрашивает вас, что вы сделали за последний месяц, легко показать крутой графический интерфейс. Трудно показать крутой API. Очень сложно. Прохлательность API очевидна только благодаря фактическому использованию - его нельзя ценить с первого взгляда.
Вы можете сойти с рук со всеми видами хака и ярлыков во внутренних системах. При работе с графическим интерфейсом у вас нет такой свободы. Ваш внутренний API может иметь несоответствие, и вы просто ожидаете, что кодеры справится с ним, потому что его слишком сложно исправить. Вы не можете пытаться и заставить своих клиентов делать то же самое. Таким образом, в некотором смысле, люди, которым приходится иметь дело с видимыми компонентами пользователя, должны фактически следовать более высоким стандартам.
Я собираюсь сказать «да», по одной простой причине: iPhone. Все, с кем я когда -либо говорил, думают, что это фантастика из -за гладкого интерфейса, но я могу только представить работу внизу, чтобы сделать все возможным.
Это зависит от аудитории. Я работаю со многими финансовыми аналитиками, и их представление о хорошем дизайне графического интерфейса имеет столько областей, сколько вы можете дать в одну форму. Серьезно, я говорю 75 - 100. Это наркоманы, которые всегда хотят большего. Недавно я улучшил производительность в нескольких сохраненных процедурах, которые могут занять 45 секунд для загрузки (рассчитайте весовые средние значения с начала времени). Получил до 30 секунд; Я думаю, вау, разрезай одну треть времени; Это должна быть позиция на моем резюме. Никто даже не заметил. Продолжал работать над этим и достал 15-20. Заметное изменение. Все были очень счастливы. Я все еще думаю, что графический интерфейс является мерзостью, и если мы вытащим это бесполезное дерьмо, он загрузится через 2 секунды, но когда будет 15 различных многострочных текстовых поксов (вы знаете те, у кого есть все возможности формирования с максимальными настройками символов. .), это безнадежно.
Поэтому, если вы хотите, чтобы пользователи действительно любили вас, помните, что лучший пользовательский интерфейс вообще не является интерфейсом (желаю, чтобы я вспомнил, кто это сказал). После желания увидеть все эти данные, мои аналитики поняли, что это те, кто выполняет весь ввод данных - ужас.
Тестирование частей пользовательского интерфейса приложения - кошмар.
Каждый человек, окружающий, чувствует себя компетентным, чтобы дать советы или удовлетворить требование, как вы должны это делать.
После того, как система работает нормально, позже, даже если кто -то, возможно, случайно вспомнит, кто он добродетель в ней, никто не помнит, кто что сделал.
Но если будет видно какая -либо ошибка (немного Всегда случается), первым, кто будет осужден, будет программист GUI, пользователь просто никогда не видел других!
