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

Багато програмістів, яких я зустрічав, завжди говорить про те, що "він не хлопець з інтерфейсу". Справа в тому, що розробка на сьогоднішній день, будь то веб, Windows, Linux, OSX чи будь-який інший тип розробки, тепер включає програмне забезпечення з гарним інтерфейсом користувача. Чому так багато розробників, здається, не люблять роботу інтерфейсу?

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

Крім того, я думаю, що це більше нудьга, ніж ненависть. Розробка інтерфейсу є важкою та складною частиною. Реалізація - це переважно груба робота. У тому, як можна реалізувати користувальницький інтерфейс, існує дуже мало викликів чи нововведень, і лише стільки разів можна поставити прапорець на екрані, перш ніж трохи подумати. І це навіть не торкається витрачати години на вирівнювання пікселів "просто так".

Створення хорошого інтерфейсу передбачає багато різних навичок, ніж написання деякого резервного коду.

Зазвичай вимоги зазвичай можна вказати, як чорний ящик, x входить і очікується, що y має вийти. Робота з ним передбачає реалізацію логіки, і ви можете програмно перевірити, працює вона чи ні.

Щоб зробити хороший інтерфейс користувача, вам потрібно врахувати зручність використання, візуальний дизайн, макет і такі речі, як кольорові схеми. Мати художню творчість - це бонус, і багато програмістів не відчувають, що вони мають це. Логічному мозку рішення проблеми інтерфейсу може здатися суб'єктивним, оскільки немає жодної правильної відповіді чи простого способу перевірити, що це зроблено "правильно".

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

Звичайно, деякі програмісти не мають проблеми з цим аспектом, але ненавидять його, оскільки багато інтерфейсів просто нудно кодувати. Вони можуть складатися з безлічі повторюваних робіт, таких як сторінки форм для сторінок адміністратора, де вони просто повинні бути функціональними і немає проблем із дизайном.

Люди просто мають різні інтереси. Деяких програмістів більше цікавлять структури даних та алгоритми, деякі - архітектура, деякі - зручність використання та дизайн інтерфейсу, або будь-яка комбінація цих та інших ніш. Кожен з них вимагає різних навичок та різних способів думати про проблему. Якщо вам подобаються гайки та болти програмування низького рівня, можливо, ви не так переймаєтесь тим, як думає користувач, або навпаки.

Особисто я потрапляю в останній табір - я б швидше створив інтерфейс, ніж складний алгоритм. Це якраз та річ, яка мені здається цікавою.

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

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

Я особисто не насолоджуюся розвитком інтерфейсу, тому що мені це не добре. Є ВЕЛИЧИЙ елемент психології користувачів, який я просто не добре розумію. Я думаю, що найбільшим моїм питанням є те, що я не можу поставити себе взуття користувача. Я не знаю, як зробити інтуїтивно зрозумілі макети, бо я не знаю, що інтуїтивно зрозуміло для користувача, і не знаю, як зробити так, щоб речі виглядали красиво.

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

Проблема дизайну інтерфейсу полягає в тому, що всі мають думку ... І немає правильної чи неправильної відповіді. З іншого боку, розробники люблять чорно-білі та логіку. У будь-якій компанії розміру всі погодиться з цим 1+1=2, але запитайте, який шрифт найпростіше читати (Comic Sans Obviously)... готуйтеся до потопу. Десять тисяч різних відповідей, і кожен правий, бо всі різні.

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

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

З іншого боку, я ненавиджу речі низького рівня. Я ніколи не торкаюся коду для драйверів, ядер чи іншого подібного: shudder: Я залишаю це "хлопцям, які не користуються інтерфейсом", і я щасливий, що хтось інший любить це робити, або це ніколи не зробиться.

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

Хороше джерело для подальшого читання цієї теми.

Розвиток інтерфейсу стає складним, оскільки ви отримуєте занадто багато коштів від неправильних людей. Всі вони експерти з графічного дизайну. Їх немає де знайти, коли ви хочете знати формулу чогось.

Вони не знають, чого хочуть, але знають це, коли бачать, не мають смаку, і ті, хто має рішення, не використовуватимуть додаток все одно, але впевнені, що він повинен бути зеленим. Ви дотримуєтесь інструкцій щодо хорошого інтерфейсу, наприклад обмеження кількості полів у формі, і ви отримуєте запит на додавання ще 50 полів, оскільки вони "потребують" їх усіх, а наявність їх на окремих вкладках - це занадто багато зусиль. Ви знаєте, те саме, що в Excel. Селяни!

Ви не можете це придумати. Я сидів на нараді, де двоє перших у бухгалтерії (близько 500 тис. Дол. / Рік зарплати) великої юридичної фірми витратили півгодини, сперечаючись над міткою на сторінці виставлених рахунків веб-сайтів, яку використовували юристи. Це, мабуть, полегшило розуміння юристів. Чому б просто не попросити юристів? Занадто просто. Тож ІТ-відділ потрапляє на 50 телефонних дзвінків від адвокатів, які хочуть дізнатися WTF "Сума залишкової чистої виставлення рахунків", і чому це знаходиться у формі реєстрації часу.

Деякі люблять брокколі, деякі ні. Нам, можливо, доведеться її з'їсти, але нам це не потрібно, і ми не збираємось насолоджуватися цим, коли їмо. Мало того, ми не будемо їсти його стільки, скільки можливо.

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

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

У розробці інтерфейсу користувача є певні речі, які важко отримати правильно.

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

Інша - маршрутизація подій - навіть із архітектурою MVP та елементами, накладеними рамками, я можу стверджувати, що у більшості складних інтерфейсів є проблеми з маршрутизацією подій - які можуть бути виявлені, якби будь-яка з тестових фреймворків могла їх добре вирішити.

Я знаю, що для мене я ненавиджу розроблений інтерфейс користувача, тому що вважаю його дуже нудним і повільним, особливо пишучи код верстки для розташування речей у формі чи віні. Зараз із інструментами дизайнера інтерфейсу, такими як дизайнер форм у Visual Studio, мені це майже подобається . Інші причини його ненависті, які я чув від інших, включали "це дурно", "це завжди занадто сильно змінюється", "це не досить складно", "це нудно / нудно".

Чому всі шахісти не люблять конструювати шахові дошки та фігури, з якими вони грають?

Це не дивно, що деяким людям це не подобається ... дивно, що ти очікуєш, що ми повинні.

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

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

Тож у цьому відношенні написання програм GUI - це більше аспект використання фреймворків, які мені не подобаються.

Є ще один аспект. Я часто працюю з «корпоративним» додатком, тобто додатками, де настільний додаток повинен отримувати дані з сервера. У цьому випадку існує стільки шарів перетворення даних з одного формату в інший, що стає дійсно нудно.

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

Тобто багато разів однакові дані представлені різними класами. І це стає нудно. Але це проблема, характерна для цього типу настільних додатків.

Також у цього типу додатків є цікаві проблеми, такі як, як ми отримуємо зміни від одного клієнта для негайного оновлення іншого клієнта.

Я не є великим шанувальником розвитку інтерфейсу з цих причин:

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

2. Користувальницький інтерфейс є більш м'яким, тоді як задній кінець більш "платонічний". Хоча я бачив некрасиві помилки коду, я думаю, що це звичайніше, щоб він був чистим (з точки зору коду), ніж код UI. Користувацький інтерфейс може бути справді чистим і добре розробленим для користувача, але оскільки я розробник і витрачаю більше часу на код, ніж його використовую, я більше люблю чистити код.

3. Я відчуваю, що інтерфейс швидше "сантехнічний", ніж бек-енд, тобто менше можливостей для розумних алгоритмів і справді штовхає ваш мозок до межі.

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

Сума, яка мені подобається або не подобається, залежить від того, наскільки я можу зробити, використовуючи щось на зразок мови, що залежить від домену (DSL).

У домені інтерфейсу користувача те, що я представляю користувачам, і складність інформації, яку я отримую від них, така, що я б зійшов з розуму, якби мені довелося використовувати типові інструменти, як-от дизайнери форм, безліч обробників подій, MVC , все те "найсучасніше" речі. На щастя, десятиліття тому я виявив, що, на мою думку, є кращим способом, а це зробити DSL для цього та працювати над цим. В даний час я називаю це "Динамічні діалоги", і він заснований на структурі управління, яку я називаю " Диференційне виконання" . Хороша новина в тому, що для даної функціональності вихідний код приблизно на порядок менший, що дозволяє мені вводити набагато більше функціональних можливостей в інтерфейс користувача. Погана новина полягає в тому, що, як я намагався цього навчити, я не мав великої удачі в передачі технології.

У домені, що не користується користувальницьким інтерфейсом, я взяв урок з ряду продуктів, які розпочалися як DSL, які можна використовувати з командного рядка, на який пізніше був призначений інтерфейс користувача. Це дає експертові щось, де вони можуть обійти користувальницький інтерфейс, а випадковому користувачеві дати щось, що вони можуть використовувати випадково. (Приклади: R, SPlus, Matlab, SAS, WinBugs.) Отже, наш продукт має мову командного рядка для експертів. Я люблю розробляти такі речі за допомогою аналізатора, генератора коду, прекомпілятора та двигуна моделювання часу. Зусилля, витрачені на це, принаймні, на 10 разів менше, ніж зусилля, витрачене на користувальницький інтерфейс.

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

Отже, ваше запитання було "Чому деякі програмісти ненавидять частину розробки інтерфейсу?". Я ненавиджу його лише через той "клей", для якого у мене немає DSL.

Чесно кажучи, я вважаю, що знайти найкращий інструментарій графічного інтерфейсу, а потім насправді вивчити все, що таке - ПІДА ... не кажучи вже про те, що ти не вивчаєш багато предметів інтерфейсу в коледжі, і я так новачок ...... так ..

Крім того, що вже було сказано (це копітка, нудна, розчаровує робота над її кодуванням, і дизайн, як правило, виконується тим, хто не має поняття, які проблеми викликають його ідеї для тих, хто намагається їх реалізувати), важливим фактором є те, що ви Вам доведеться працювати з людьми, чиї уявлення про те, що вам слід робити, змінюються постійно, набагато більше, ніж вони роблять для бекенда. Як результат, ти ще більше стріляєш проти рухомих примірників, і ці люди теж, як правило, піддаються аніме. У мене буквально проходять тести провалу користувальницьких інтерфейсів, оскільки компонент був на 1 піксель від місця, де людина, що його тестує, вважала, що це має бути. Це спрацювало? Так. Це добре виглядало? Так. Але він почав рахувати пікселі, і щось було в одному пікселі не в порядку з рештою, тому він відправив його назад для переробки.

Ще кілька пунктів:

1) Дизайн інтерфейсу може бути складнішим для перевірки, впевнений, що ви можете перевірити, чи ця кнопка виконує все, що слід, але протестувати, чи зручно у використанні, що складніше. Як щодо тестування, чи воно буде корисним для когось із інвалідністю?

2) Багато програмістів на цьому не навчаються і не знають багато про це.

Справа в тому, що багато інструментів інтерфейсу / фреймворк / API погані, складні, далеко не інтуїтивні. Я розробляв за допомогою API Win32 в C / C ++, з javax.swing, CSS і т. Д. З цього я ненавиджу мати справу з розробкою інтерфейсу ... До Qt Framework!

Як студент CS, вас навчать структурі даних, базі даних, C ++ ... крім UI. Тож вам не буде добре в цьому від початку . Якщо ти не добрий у цьому, ти будеш ненавидіти це.

Опрацювавши обидві сторони монети, тобто дизайн інтерфейсу та коду, що з'явився, я виявив, що обидві сторони монети - це одна і та ж річ.

Вимоги, що відрізняються від того, що ви робите щодня, не виникають постійно і зараз в епоху, коли всі служби обертаються навколо CRUD, то стає нудно.

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