I programmatori della GUI hanno un indebito vantaggio sugli altri?

È facile per manager e clienti apprezzare ciò che possono vedere.

Ho visto molti sviluppatori di GUI che sono programmatori medi con una minima conoscenza dei principi di progettazione o di altri modi di programmare. Tuttavia, queste carenze spesso passano inosservate, specialmente da parte della direzione e dei clienti, se il programmatore può creare un'interfaccia utente dall'aspetto impressionante. Tanto che molti sviluppatori di GUI che conosco passano ore ad abbellire la GUI a spese di scrivere codice cattivo, non mantenibile.

D'altra parte, i programmatori di livello intermedio che sviluppano API o funzionalità aziendali o codice di database (SQL ecc.) Sono in svantaggio in quanto non c'è nulla di tangibile da mostrare. Forse un revisore del codice o un architetto possono apprezzare l'eleganza, il buon design, la scalabilità ecc. Del codice, ma non significa nulla per il mondo esterno. Il codice può essere eseguito per anni senza interruzione, può essere molto facile da mantenere e avere buone prestazioni, ma non suscita mai il "wow" che fa una GUI dall'aspetto slick.

A mio avviso, un corollario di ciò è (e lo farò fortemente sottovalutato per questo, lo so) che c'è meno motivazione per un programmatore della GUI a scrivere un buon codice pulito.

EDIT : Devo spiegare qui che per programmatore della GUI, non intendo un vero progettista web / GUI ma un programmatore front-end, ad esempio un programmatore java-swing.

Il resto della comunità è d'accordo?

Penso di vedere il tuo punto, ma sospetto che ci sia anche un problema opposto da considerare.

In sostanza, credo che tu stia suggerendo che, poiché l'interfaccia utente è l'elemento dell'applicazione "di fronte" agli utenti finali, gli sviluppatori dell'interfaccia utente godono di una maggiore visibilità rispetto ai membri del team che lavorano in strati più profondi dell'app.

Certamente sono d'accordo che potrebbe esserci una maggiore visibilità. Ad esempio, gli sviluppatori che lavorano sugli elementi dell'interfaccia utente possono interagire con gli utenti finali più spesso (probabilmente, per buoni motivi, poiché si concentrano sull'aspetto dell'interazione uomo / computer).

Tuttavia, penso che la maggiore visibilità entri in gioco anche nei casi in cui c'è un problema. Ad esempio, è molto probabile che gli utenti finali segnalino i problemi come "Problemi della GUI" anche quando non lo sono.

Tutto può ridursi alla percezione e un'organizzazione matura dovrebbe essere in grado di riconoscere valori, virtù e punti deboli dei vari membri del team indipendentemente dal livello dell'app su cui lavorano. Un'organizzazione matura potrebbe anche essere andata oltre le distinzioni come "sviluppatore dell'interfaccia utente" e "sviluppatore del livello aziendale", riconoscendo che sono comunque tutti membri del team, con forse diverse competenze, ma sempre cercando di educarsi a vicenda su quelle aree di competenza.

Per una persona che non ha a che fare con i programmatori, posso dire con certezza che crederebbero a questo tipo di cose. Non conoscono la quantità di lavoro che va in background, vedono solo un gruppo di pulsanti / caselle di testo / menu / [inserire elemento GUI] e la velocità necessaria per realizzare ciò che il pulsante ha iniziato. Quindi inizialmente, alle persone della GUI piace di più.

Se la persona ha a che fare con i programmatori, allora è un po 'diverso. Come hai detto, noterebbero se lo rendessi scalabile, più facile da mantenere, riscrivendo un algoritmo in modo che avesse più senso o qualsiasi altra attività di manutenzione. Questo tipo di persona guarderebbe tutti i programmatori allo stesso modo.

Nel mezzo dipende da cosa stai facendo. La velocità diventa quindi il fattore importante qui. Se riesci a mostrare prima e dopo le registrazioni di quanto tempo impiega un modulo per essere elaborato e memorizzato e c'è un miglioramento, sei uguale. Se puoi mostrare l'app sotto carico da 100 client e mostrare loro che il server si sta sciogliendo, e quindi mostrare loro la tua versione in cui tutto va bene, il tuo uguale. Eccetera.

In breve, dipende dalla persona e da cosa stai facendo.

Come "esperto di UI" nella mia azienda (il responsabile di tutto lo sviluppo dell'interfaccia utente, non solo del design), penso che potresti perdere parte della storia. Mentre sono il responsabile dell'interfaccia utente, lavoro anche sul back-end, sui database, ecc. Faccio tutto (siamo una piccola squadra). [Sviluppo C # e ASP.Net WebForms]

Prima di tutto, sì, è molto più facile per le persone non tecniche apprezzare il lavoro di uno sviluppatore di GUI perché è quello che si trova di fronte alle persone. Per le persone non tecniche, la GUI è l'applicazione . Lo svantaggio è che la GUI è anche la prima ad essere incolpata quando qualcosa va storto.

In secondo luogo, lo sviluppo del front-end è stato per me molto più impegnativo di quanto non lo sia mai stato il back-end (a parte oscuri / complessi algoritmi). C'è molto di più da evitare, è apolide (le nostre app sono sul Web), i browser non si comportano in modo coerente (le librerie JavaScript erano una manna dal cielo), ecc. Spero che la maggior parte di questa complessità sia dovuta al framework che ho lavorare con (ASP.Net WebForms) e che tutte le cose difficili non saranno un problema in futuro.

Nel complesso, ho avuto molte più difficoltà a risolvere i problemi dell'interfaccia utente rispetto ai problemi di back-end.

Odio lo sviluppo della GUI per due motivi,

1. Sono più logico che grafico dal punto di vista artistico e la mia UI ne risente sempre.
2. Poiché l'interfaccia utente non si basa sulla logica, i test unitari sono quasi impossibili da scrivere con qualsiasi significato

Alla fine, tuttavia, penso che il mio codice sarà meglio apprezzato dall'utente finale (al contrario, forse per uno sponsor del progetto), rispetto a quello di uno sviluppatore mediocre che è un mago dell'interfaccia utente, poiché generalmente funziona .

Per (forse) espandere un po 'la risposta di @ TheLQ, penso che dipenda anche dal "visualizzatore".

Ho avuto qualche esperienza con alcuni manager / supervisori di livello superiore che non hanno un background di programmazione. Alcuni apprezzano che non programmano, ma comprendono che Chrome e coprimozzi sono importanti tanto quanto il motore e il telaio.

E ho avuto esperienza con alcuni manager / supervisori di livello superiore che non si preoccupano di metriche diverse dall'interfaccia utente. Anche affermando che gli sviluppatori più orientati all'interfaccia utente erano importanti.

IMHO, sappiamo tutti che non puoi lucidare un turd e un'app veloce, affidabile ma brutta sarà molto peggio di un'app che sia bella e funzionante. È tutto negli occhi di chi guarda e, in una certa misura, hai il potere (indipendentemente da ciò che fai) di essere visto nella luce che desideri, lavorando per coloro che apprezzano le tue stesse qualità.

EDIT: potrei aggiungere, essendo qualcuno che si sente più a suo agio a lavorare su oggetti di livello inferiore, sono stato stanco quando lavori altrettanto duramente come il team dell'interfaccia utente ed è il lucido che è lodato nella demo e non il fatto che il sistema " appena lavorato ". Ma come ho detto, so che il mio supervisore sa che il lavoro è necessario in tutte le aree.

Penso che ci sia una presunzione generale là fuori che gli sviluppatori dell'interfaccia utente sono gli sviluppatori "junior". Posso solo pensare a un caso in cui mi sono imbattuto in un ragazzo dell'interfaccia utente considerato senior.

Detto questo, penso che l'interfaccia utente sia molto più difficile di qualsiasi altra parte delle nostre app. E non sto parlando del design UX, sto parlando della codifica. Quante altre aree codifichiamo in cui dobbiamo tenere conto di dozzine, se non di centinaia, o di possibili scenari? Il ridimensionamento di uno schermo a volte può diventare un dolore reale quando devi capire cosa deve accadere con un paio di dozzine di elementi. Questo si presenta principalmente quando si hanno linee guida che dicono "dobbiamo supportare 800x600" e quindi i progettisti di UX che non usano mai altro che risoluzioni HD.

Quindi, se ottengono più bontà a causa di una maggiore esposizione, probabilmente se lo meritano. Di solito, si trovano dalla parte di ricezione sbagliata più spesso della parte di ricezione buona.

Spesso sembra esserci l'idea che un programmatore della GUI sia in fondo alla catena dei programmatori. Quanto può essere difficile trascinare e rilasciare un pulsante in VS in un modulo? Cosa, ci vorrà una settimana per programmarlo? Sta disegnando alcune barre. Quindi non sono sorpreso di vedere l'idea che i programmatori della GUI, essendo i pulsanti trascinatori così come sono, debbano scrivere anche un codice orribile.

La programmazione della GUI presenta alcune sfide uniche. Multithreading per mantenere attiva la GUI durante il caricamento dei dati. Questo porta a un codice thread sicuro e corretto. Le prestazioni sono molto importanti. A nessuno piace aspettare due minuti fino a quando non ottengono nuovamente il controllo dell'applicazione. Anche la riutilizzabilità diventa un grosso problema. Se devi scrivere dieci schermate simili, è meglio strutturare bene il codice. Questo porta a un codice migliore. E naturalmente creare una buona interfaccia grafica è una sfida in sé.

Ma per alcune persone trascinerà semplicemente un pulsante sulla tua app. Proprio come per alcune persone la logica aziendale non è altro che "analizzare un messaggio e inserirlo nel DB".

Penso che sia ovvio che lo facciano. Forse le case di sviluppo di prim'ordine sono esenti, ma la maggior parte non lo sono.

Quando il tuo manager ti chiede cosa hai fatto nell'ultimo mese, è facile mostrare una bella interfaccia grafica. È difficile mostrare un'API interessante. Molto difficile. La freddezza dell'API è evidente solo attraverso l'uso effettivo - non può essere apprezzata a colpo d'occhio.

Puoi cavartela con qualsiasi tipo di hacking e scorciatoie nei sistemi interni. Quando hai a che fare con la GUI non hai quella libertà. L'API interno potrebbe presentare un'incoerenza e ti aspetti che i programmatori lo gestiscano perché è troppo difficile da risolvere. Non puoi provare e fare in modo che i tuoi clienti facciano la stessa cosa. Quindi, in un certo senso, le persone che hanno a che fare con i componenti visibili dell'utente devono effettivamente seguire uno standard più elevato.

Sto per dire di sì, per un semplice motivo: l'iPhone. Tutti quelli con cui ho mai parlato pensano che sia fantastico grazie all'interfaccia intuitiva, ma posso solo immaginare il lavoro sottostante per renderlo possibile.

Dipende dal pubblico. Lavoro con molti analisti finanziari e la loro idea di un buon progetto di gui è quella che ha il maggior numero di campi che puoi eventualmente inceppare su un modulo. Seriamente, sto parlando tra 75 e 100. Sono drogati di dati che vogliono sempre di più. Di recente ho migliorato le prestazioni su alcune procedure memorizzate che potrebbero richiedere 45 secondi per il caricamento (calcolare le medie ponderate dall'inizio del tempo). Sono arrivato a 30 secondi; Sto pensando wow, tagliare un terzo delle volte; dovrebbe essere un elemento pubblicitario sul mio curriculum. Nessuno se ne è nemmeno accorto. Ho continuato a lavorarci su e l'ho portato al 15-20. Notevole cambiamento. Tutti erano molto felici. Penso ancora che la GUI sia un abominio e se eliminassimo questa inutile schifezza, si caricerebbe in 2 secondi,

Quindi, se vuoi che gli utenti ti amino davvero, ricorda che la migliore interfaccia utente non è affatto un'interfaccia (vorrei che mi ricordassi chi l'ha detto). Dopo aver voluto vedere tutti questi dati, i miei analisti hanno capito che sono loro a fare tutti i dati: l'orrore.

Testare parti dell'interfaccia utente dell'applicazione è un incubo.

Ogni persona in giro si sente competente a dare un consiglio o a chiedere come dovresti farlo.

Dopo che il sistema funziona correttamente, in seguito anche se qualcuno ricorda accidentalmente chi ha la virtù, nessuno ricorderà chi ha fatto cosa.

Ma se viene visualizzato un errore ( alcuni accadono sempre), il primo uomo ad essere condannato sarà il programmatore della GUI, l'utente semplicemente non aveva mai visto gli altri!