Czy programiści GUI mają nieuzasadnioną przewagę nad innymi?

Menedżerom i klientom łatwo jest docenić to, co widzą.

Widziałem wielu programistów GUI, którzy są przeciętnymi programistami z minimalną znajomością zasad projektowania lub innych idiomów programistycznych. Jednak te niedociągnięcia często pozostają niezauważone, szczególnie przez kierownictwo i klientów, jeśli programista może stworzyć imponująco wyglądający interfejs użytkownika. Do tego stopnia, że ​​wielu programistów GUI, które znam, spędza godziny na upiększaniu GUI kosztem pisania złego, niemożliwego do utrzymania kodu.

Z drugiej strony programiści warstwy średniej, którzy opracowują interfejsy API lub funkcje biznesowe lub kod bazy danych (SQLs itp.), Są w gorszej sytuacji, ponieważ nie ma nic namacalnego do zaprezentowania. Być może recenzent kodu lub architekt może docenić elegancję, dobry design, skalowalność itp. Kodu, ale nie znaczy to dla świata zewnętrznego. Twój kod może działać przez wiele lat bez zepsucia, może być bardzo łatwy w utrzymaniu i ma dobrą wydajność, ale nigdy nie wywołuje „wow”, który robi zgrabnie wyglądający GUI.

Moim zdaniem, następstwem tego jest (i mam zamiar zostać za to mocno doceniony, wiem), że programista GUI ma mniej motywacji do pisania dobrego, czystego kodu.

EDYCJA : Muszę tu wyjaśnić, że przez programistę GUI nie mam na myśli pełnoprawnego projektanta stron internetowych / GUI, ale programistę front-endową, np. Programistę Java.

Czy reszta społeczności się zgadza?

Wydaje mi się, że rozumiem twój punkt widzenia, ale podejrzewam, że należy również rozważyć przeciwną kwestię.

Zasadniczo uważam, że sugerujesz, że ponieważ interfejs użytkownika jest elementem aplikacji „w obliczu” użytkowników końcowych, programiści interfejsu użytkownika cieszą się lepszą widocznością niż członkowie zespołu pracujący w głębszych warstwach aplikacji.

Z pewnością zgadzam się, że widoczność może być wyższa. Na przykład programiści pracujący nad elementami interfejsu użytkownika mogą częściej wchodzić w interakcje z użytkownikami końcowymi (prawdopodobnie z dobrych powodów, ponieważ koncentrują się na aspekcie interakcji człowiek / komputer).

Uważam jednak, że w grę wchodzi większa widoczność, nawet w przypadku problemów. Na przykład użytkownicy końcowi z dużym prawdopodobieństwem zgłaszają problemy jako „problemy z GUI”, nawet jeśli nie są.

Wszystko może sprowadzać się do percepcji, a dojrzała organizacja powinna być w stanie rozpoznać wartości, zalety i słabości różnych członków zespołu niezależnie od tego, na której warstwie aplikacji pracują. Dojrzała organizacja mogła także wyjść poza takie rozróżnienia, jak „programista interfejsu użytkownika” i „programista warstwy biznesowej”, uznając, że i tak wszyscy są członkami zespołu, z różnym doświadczeniem, ale zawsze starając się wzajemnie edukować w tych obszarach wiedzy.

Dla osoby, która nie ma do czynienia z programistami, mogę śmiało powiedzieć, że uwierzyliby w takie rzeczy. Nie znają nakładu pracy w tle, wszystko, co widzą, to kilka przycisków / pól tekstowych / menu / [wstaw element GUI] i szybkość, jaką zajmuje osiągnięcie tego przycisku. Początkowo ludzie z GUI są bardziej lubiani.

Jeśli dana osoba ma do czynienia z programistami, to jest trochę inaczej. Jak powiedziałeś, zauważyliby, gdybyś uczynił go skalowalnym, łatwiejszym w utrzymaniu, przepisał algorytm, aby był bardziej sensowny, lub wykonał inne zadanie typu konserwacji. Ten rodzaj osoby patrzyłby jednakowo na wszystkich programistów.

W środku zależy to od tego, co robisz. Ważnym czynnikiem staje się tutaj prędkość. Jeśli potrafisz pokazać przed i po nagraniu, ile czasu zajmuje przetworzenie i zapisanie formularza oraz czy nastąpiła poprawa, jesteś równy. Jeśli możesz pokazać aplikację pod obciążeniem od 100 klientów i pokazać im topnienie serwera, a następnie pokazać im swoją wersję, w której wszystko jest w porządku, równa się. Itp.

Krótko mówiąc, zależy to od osoby i tego, co robisz.

Jako „ekspert ds. Interfejsu użytkownika” w mojej firmie (odpowiedzialny za cały rozwój interfejsu użytkownika, a nie tylko jego projektowanie), myślę, że może brakuje ci części historii. Chociaż jestem facetem odpowiedzialnym za interfejs użytkownika, pracuję również nad zapleczem, bazami danych itp. Robię to wszystko (jesteśmy małym zespołem). [Rozwój C # i ASP.Net WebForms]

Po pierwsze, tak, osobom nietechnicznym o wiele łatwiej jest docenić pracę programisty GUI, ponieważ to właśnie dzieje się przed ludźmi. Dla osób nietechnicznych GUI jest aplikacją . Wadą jest to, że GUI jest również pierwszym, którego należy obwiniać, gdy coś pójdzie nie tak.

Po drugie, opracowanie front-endu było dla mnie o wiele trudniejsze niż back-end (kiedykolwiek niejasne / złożone algorytmy). Jest o wiele więcej rzeczy, przed którymi trzeba się bronić, jest bezstanowy (nasze aplikacje są w Internecie), przeglądarki nie zachowują się konsekwentnie (biblioteki JavaScript były darem niebios) itp. Mam nadzieję, że większość tej złożoności wynika z ram, które mam pracować z (ASP.Net WebForms) i że wszystkie trudne rzeczy nie będą stanowić problemu w przyszłości.

Ogólnie miałem znacznie więcej trudności w rozwiązywaniu problemów z interfejsem użytkownika niż problemów z zapleczem.

Nienawidzę programowania GUI z dwóch powodów,

1. Jestem bardziej logiczny niż graficznie, a mój interfejs zawsze cierpi z tego powodu.
2. Ponieważ interfejs użytkownika nie jest oparty na logice, prawie niemożliwe jest pisanie testów jednostkowych o dowolnym znaczeniu

Pod koniec dnia uważam jednak, że mój kod będzie bardziej doceniany przez użytkownika końcowego (w przeciwieństwie do sponsora projektu), niż przez miernego programistę, który jest świstem w interfejsie użytkownika, ponieważ ogólnie działa .

Aby (być może) nieco rozwinąć odpowiedź @ TheLQ, myślę, że zależy to również od „przeglądarki”.

Mam doświadczenie z kilkoma menedżerami / przełożonymi wyższego szczebla, którzy nie mają doświadczenia w programowaniu. Niektórzy doceniają to, że nie programują, ale rozumieją, że chrom i kołpaki są równie ważne jak silnik i podwozie.

I miałem doświadczenie z niektórymi menedżerami / przełożonymi wyższego szczebla, którzy nie dbają o żadne inne wskaźniki niż skwierczenie interfejsu użytkownika. Nawet stwierdzenie, że deweloperzy zorientowani na interfejs użytkownika są ważni.

IMHO, wszyscy wiemy, że nie można wypolerować gówna, a szybka, niezawodna, ale brzydka aplikacja będzie znacznie gorsza niż aplikacja, która zarówno wygląda dobrze, jak i działa dobrze. Wszystko zależy od widza i do tego stopnia, że ​​masz moc (niezależnie od tego, co robisz), aby być widocznym w pożądanym świetle, pracując dla tych, którzy doceniają te same cechy, co ty.

EDYCJA: Dodam, że będąc kimś, kto czuje się bardziej komfortowo pracując nad przedmiotami niższego poziomu, byłem zmęczony, gdy pracujesz równie ciężko jak zespół interfejsu użytkownika, a polską chwalono w wersji demo, a nie fakt, że system „ właśnie działało ”. Ale tak jak powiedziałem, wiem, że mój przełożony wie, że praca jest potrzebna we wszystkich obszarach.

Myślę, że istnieje ogólne domniemanie, że programiści interfejsu użytkownika są programistami „młodszymi”. Mogę wymyślić tylko jeden przypadek, w którym natknąłem się na faceta z UI.

To powiedziawszy, myślę, że interfejs użytkownika jest znacznie trudniejszy niż jakakolwiek inna część naszych aplikacji. I nie mówię o projekcie UX, mówię o kodowaniu. Ile innych obszarów kodujemy, w których musimy uwzględnić dziesiątki, jeśli nie setki, lub możliwe scenariusze? Po prostu zmiana rozmiaru ekranu może czasem stać się królewskim bólem, gdy musisz dowiedzieć się, co się stanie z kilkoma tuzinami elementów. Pojawia się to przede wszystkim, gdy masz wytyczne, które mówią „musimy wesprzeć 800x600”, a następnie projektantów UX, którzy nigdy nie używają niczego innego niż rozdzielczości HD.

Jeśli więc dostaną więcej dobroci z powodu większej ekspozycji, prawdopodobnie zasługują na to. Zwykle częściej znajdują się na niewłaściwym końcu odbiorczym niż na dobrym końcu odbiorczym.

Często wydaje się, że programista GUI znajduje się na dole łańcucha programistów. Jak trudne może być przeciągnięcie i upuszczenie przycisku w VS do formularza? Co zajmie ci tydzień zaprogramowanie tego? Rysuje kilka pasków. Nie dziwi mnie więc myśl, że programiści GUI, którzy są przyciskami do przeciągania przycisków, również muszą pisać okropny kod.

Programowanie GUI ma kilka wyjątkowych wyzwań. Wielowątkowość, aby utrzymać GUI aktywne podczas ładowania danych. Prowadzi to do wątku bezpiecznego i właściwego kodu. Wydajność jest bardzo ważna. Nikt nie lubi czekać dwie minuty, aż ponownie przejmie kontrolę nad aplikacją. Ponowne wykorzystanie staje się również dużym problemem. Jeśli musisz napisać dziesięć podobnych ekranów, lepiej dobrze ułóż kod. To prowadzi do lepszego kodu. I oczywiście stworzenie dobrego GUI jest wyzwaniem samym w sobie.

Ale dla niektórych osób będzie to po prostu przeciągnięcie przycisku do Twojej aplikacji. Podobnie jak w przypadku niektórych osób, logika biznesowa jest niczym innym jak „parsowaniem wiadomości i umieszczaniem jej w bazie danych”.

Myślę, że to oczywiste, że tak. Być może domy deweloperów na najwyższym poziomie są zwolnione, ale większość innych nie.

Gdy Twój menedżer zapyta Cię, co zrobiłeś w ciągu ostatniego miesiąca, łatwo jest pokazać fajny interfejs GUI. Trudno pokazać fajne API. Bardzo trudny. Chłodzenie interfejsu API jest widoczne tylko poprzez faktyczne użycie - nie można tego ocenić na pierwszy rzut oka.

Możesz uciec od wszelkiego rodzaju hakerów i skrótów w systemach wewnętrznych. Podczas pracy z GUI nie masz takiej swobody. Twój wewnętrzny interfejs API może być niespójny i po prostu oczekujesz, że kodery sobie z tym poradzą, ponieważ jest to zbyt trudne do naprawienia. Nie możesz próbować zmusić klientów do zrobienia tego samego. W pewnym sensie ludzie, którzy mają do czynienia z komponentami widocznymi dla użytkownika, muszą w rzeczywistości stosować wyższy standard.

Powiem tak, z jednego prostego powodu: iPhone. Wszyscy, z którymi kiedykolwiek rozmawiałem, uważają, że to fantastyczne ze względu na elegancki interfejs, ale mogę sobie tylko wyobrazić pracę pod spodem, aby wszystko było możliwe.

To zależy od odbiorców. Współpracuję z wieloma analitykami finansowymi, a ich pomysł na dobry projekt GUI jest taki, który ma tyle dziedzin, ile możesz zablokować w jednym formularzu. Poważnie, mówię 75 - 100. Są ćpunami danych, którzy zawsze chcą więcej. Niedawno poprawiłem wydajność kilku procedur przechowywanych, których ładowanie może zająć 45 sekund (obliczanie średnich ważonych od początku czasu). Zredukowałem to do 30 sekund; Myślę: wow, skróć jedną trzecią czasu; powinien to być element zamówienia w moim CV. Nikt nawet tego nie zauważył. Nie pracowałem nad tym i dostałem do 15-20. Zauważalna zmiana. Wszyscy byli bardzo szczęśliwi. Nadal uważam, że GUI jest obrzydliwością i gdybyśmy wzięli to bezużyteczne badziewie, załadowałoby się za 2 sekundy,

Jeśli więc chcesz, aby użytkownicy naprawdę cię kochali, pamiętaj, że najlepszym interfejsem użytkownika jest w ogóle brak interfejsu (chciałbym pamiętać, kto to powiedział). Po tym, jak chcieli zobaczyć wszystkie te dane, moi analitycy zdali sobie sprawę, że to oni wprowadzają wszystkie dane - horror.

Testowanie części interfejsu użytkownika aplikacji to koszmar.

Każda osoba w pobliżu czuje się kompetentna, aby udzielić porady lub ustalić, jak należy to zrobić.

Po tym, jak system zadziała OK, później nawet jeśli ktoś przypadkowo przypomni sobie, kto jest w nim cnotą, nikt nie będzie pamiętał, kto co zrobił.

Ale jeśli pojawi się jakikolwiek błąd ( niektóre zawsze się zdarzają), pierwszym skazanym będzie programista GUI. Użytkownik po prostu nigdy nie widział innych!