programmatori Do GUI hanno un indebito vantaggio rispetto alle altre?

https://softwareengineering.stackexchange.com/questions/11157

16-10-2019
|

Domanda

E 'facile per i gestori e clienti di apprezzare quello che possono vedere.

ho visto molti sviluppatori GUI che sono programmatori medi con una conoscenza minima di principi di progettazione o di altri idiomi di programmazione. Tuttavia, queste carenze spesso passano inosservati, soprattutto dal management e clienti, se il programmatore può creare un impressionante interfaccia utente cerca. Tanto che molti sviluppatori GUI che conosco passano ore abbellire l'interfaccia grafica a scapito di scrivere male, il codice impossibile da mantenere.

D'altra parte, i programmatori di livello intermedio che sviluppano API o funzionalità di business o codice del database (SQLs etc.) sono in svantaggio in quanto non v'è nulla di tangibile da mostrare. Forse un revisore codice o un architetto possono apprezzare l'eleganza, il buon design, scalabilità ecc di codice, ma non significa niente al mondo esterno. Il codice può funzionare per anni senza rompere, può essere molto facile da mantenere e avere buone prestazioni, ma non è mai suscita la 'wow' che una chiazza di petrolio guardando GUI fa.

A mio parere, un corollario a questo è (e sto andando ottenere pesantemente downvoted per questo, lo so) che c'è meno motivazione per un programmatore GUI per scrivere buon codice pulito.

Modifica :. Devo spiegare qui che dal programmatore GUI, non voglio dire un web / GUI designer di tutti gli effetti, ma un front-end programmatore ad esempio, un programmatore java-swing

fa il resto della comunità è d'accordo?

Soluzione

Mi sembra di vedere il vostro punto, ma ho il sospetto che ci sia anche un problema opposto a prendere in considerazione.

In sostanza, credo che lei suggerisce che, perché l'interfaccia utente è l'elemento dell'applicazione 'di fronte' degli utenti finali, gli sviluppatori dell'interfaccia utente godono di una maggiore visibilità rispetto ai membri del team che lavorano in strati più profondi della app.

Certamente sono d'accordo che ci possa essere una maggiore visibilità. Per esempio, gli sviluppatori che lavorano sugli elementi dell'interfaccia utente possono arrivare a interagire con gli utenti finali più spesso (forse, per buone ragioni, dal momento che fanno attenzione all'aspetto Human Interaction / Computer).

Tuttavia, credo che la visibilità più elevata entra in gioco, anche nei casi in cui v'è un problema. Per esempio, gli utenti finali sono molto probabilmente per problemi di rapporto come 'Questioni GUI' anche quando non lo sono.

Può tutte si riducono alla percezione, e un'organizzazione matura dovrebbe essere in grado di riconoscere i valori, le virtù e le debolezze dei vari membri del team in modo indipendente da quale livello delle app lavorano su. Un'organizzazione maturo può anche essere spostati al di là delle distinzioni come 'UI sviluppatore' e 'sviluppatore livello di business', riconoscendo che sono tutti i membri del team in ogni caso, con competenze diverse, forse, ma sempre cercando di educare l'altro su quelle aree di competenza.

Altri suggerimenti

Per una persona che non si occupa di programmatori qualsiasi, posso dire con certezza che avrebbero credere che questo genere di cose. Non conoscono la quantità di lavoro che va in background, tutto ciò che vedono è un gruppo di pulsanti / caselle di testo / menù / [inserire elementi GUI] e la velocità che serve per compiere ciò che il pulsante iniziato. Quindi inizialmente, GUI persone sono piaciuto di più.

Se la persona non accordo con i programmatori, allora è un po 'diverso. Come lei ha detto che sarebbe notare se l'hai fatta scalabile, facile da mantenere, ha riscritto un algoritmo quindi aveva più senso, o qualsiasi altro incarico tipo di manutenzione. Questo tipo di persona sarebbe guardare a tutti i programmatori allo stesso modo.

Nel mezzo dipende da cosa il vostro fare. Velocità diventa quindi il fattore importante qui. Se si riesce a mostrare, prima e dopo le registrazioni di quanto tempo ci vuole per un modulo da trattati e conservati e c'è un miglioramento, siete uguali. Se si riesce a mostrare l'applicazione sotto carico da 100 clienti e mostrare loro lo scioglimento del server, e poi mostrare loro la tua versione in cui tutto va bene, un tuo pari. Ecc.

In breve, dipende dalla persona e che cosa il vostro fare.

Come il "esperto UI" alla mia azienda (il ragazzo responsabile di tutto lo sviluppo dell'interfaccia utente, non è solo il design), penso che potrebbe essere mancante una parte della storia. Mentre io sono il ragazzo responsabile della UI, lavoro anche il sul back-end, sulle banche dati, ecc faccio tutto (siamo un piccolo team). [C # e ASP.Net WebForms sviluppo]

Prima di tutto, sì, è molto più facile per le persone non tecniche per apprezzare il lavoro di uno sviluppatore GUI, perché questo è ciò che è di fronte alla gente. Per le persone non tecniche, la GUI è l'applicazione . Lo svantaggio è che l'interfaccia grafica è anche il primo ad essere incolpato quando qualcosa va storto.

In secondo luogo, lo sviluppo del front-end è stato molto più difficile per me che il back-end sia mai stato (algoritmi oscura / complessi a parte). C'è molto di più per la guardia contro, è senza stato (le nostre applicazioni sono sul Web), i browser non si comportano in modo coerente (librerie JavaScript erano una manna dal cielo), ecc Spero che la maggior parte di questa complessità è dovuto al quadro che ho per lavorare con (ASP.Net WebForms) e che tutte le cose difficili non sarà un problema in futuro.

In generale, ho avuto molta più difficoltà di risolvere i problemi di interfaccia utente di problemi di back-end.

Odio lo sviluppo di GUI per due motivi,

Sono più logico che graficamente artistico e la mia UI soffre sempre di conseguenza.
Come UI non è basato sulla logica, unit test sono pressoché impossibili da scrivere con qualsiasi significato

Alla fine della giornata, però, penso che il mio codice sarà meglio apprezzata dall'utente finale (al contrario, forse per uno sponsor del progetto), di quella di uno sviluppatore mediocre che è un mago a UI, come generalmente funziona.

Per (forse) espandere un po 'sul @ risposta di TheLQ, penso che dipende anche dal "spettatore".

ho avuto qualche esperienza con alcuni dirigenti di livello superiore / supervisori che non hanno un background di programmazione. Alcuni apprezzano che non lo fanno programma, ma capire che Chrome e coprimozzi sono importanti tanto quanto il motore e il telaio.

E ho avuto esperienza con alcuni manager di livello superiore / supervisori che non si preoccupano di eventuali metriche diverse lo sfrigolio UI. Anche affermando che più di interfaccia utente gli sviluppatori orientati in cui importante.

IMHO, sappiamo tutti che non si può lucidare un turd e un veloce, affidabile app ancora brutto sarà molto peggio di un app che sia sembra buona e funzioni bene. E 'tutto negli occhi di chi guarda e in una certa misura, si ha il potere (indipendentemente da ciò che si fa) di essere visto alla luce che si desidera, lavorando per coloro che apprezzano le stesse qualità come te.

EDIT: Mi permetto di aggiungere, essendo qualcuno che si sente di lavoro più confortevole su elementi di livello inferiore, sono stato jaded quando si lavora altrettanto difficile come la squadra interfaccia utente ed è lo smalto che è lodato nella demo e non il fatto che il sistema "solo lavorato ". Ma come ho detto, so che i miei di supervisore conoscono il lavoro è necessaria per tutte le aree.

Credo che ci sia una presunzione generale là fuori che gli sviluppatori di UI sono gli sviluppatori "junior". Posso solo pensare a un caso in cui mi sono imbattuto in un ragazzo di interfaccia utente è stata considerata di alto livello.

Detto questo, penso interfaccia utente è molto più difficile rispetto a qualsiasi altra parte delle nostre applicazioni. E non sto parlando del disegno UX, sto parlando della codifica. Come molti altri settori dobbiamo codice dove dobbiamo conto per decine, se non centinaia, o possibili scenari? Proprio il ridimensionamento di uno schermo a volte può diventare un dolore reale quando si ha bisogno di capire che cosa deve accadere con un paio di dozzine di elementi. Questo viene in primo luogo quando si dispone di linee guida che dicono "dobbiamo sostenere 800x600" e poi UX designer che mai usare qualcosa di diverso risoluzioni HD.

Quindi, se ottengono più la bontà a causa di una maggiore esposizione, probabilmente lo meritano. Di solito, sono sul lato sbagliato sbagliato il più delle volte alla fine buona ricezione.

Non ci sembra spesso essere l'idea che un programmatore GUI è alla base della catena programmatori. Quanto sia difficile può essere quello di drag & drop su un pulsante in VS ad una forma? Che, ci vorrà una settimana per programmare questo? E 'il disegno alcuni bar. Quindi io non sono sorpreso di vedere l'idea che i programmatori GUI, essendo i trascinatori dei pulsanti come sono, devono essere la scrittura di codice orribile troppo.

programmazione GUI ha alcune sfide uniche. Multithreading per mantenere la GUI attiva durante il caricamento dei dati. Questo porta a filetto codice sicuro e corretto. Le prestazioni sono molto importante. Nessuno ama aspettare due minuti fino a ottenere il controllo dell'applicazione di nuovo. Riutilizzabilità diventa anche un grande problema. Se si deve scrivere dieci schermi simili è meglio strutturare bene il vostro codice. Questo porta a codice migliore. E, naturalmente, la creazione di una buona interfaccia grafica è una sfida in sé.

Ma per alcune persone sarà solo trascinando un pulsante per la vostra applicazione. Così come per alcune persone la logica di business non è altro che "analizzare un messaggio e metterlo nel DB".

Credo che sia ovvio che lo fanno. Forse case top-notch dev sono esenti, ma la maggior parte altri non lo sono.

Quando il direttore si chiede che cosa avete fatto nel corso dell'ultimo mese, è facile mostrare una GUI fresco. E 'difficile mostrare un'API fresco. Molto difficile. API fresco è solo apparente attraverso l'uso effettivo -. Non può essere apprezzato in generale

È possibile ottenere via con tutti i tipi di aggiustamenti e collegamenti nei sistemi interni. Quando si tratta con la GUI non si dispone di tale libertà. Il tuo api interno può avere incoerenza e basta aspettare i programmatori a che fare con esso perché è troppo difficile da risolvere. Non si può provare e rendere i vostri clienti fanno la stessa cosa. Quindi, in un certo senso, le persone che hanno a che fare con l'utente componenti visibili devono seguire in realtà uno standard più elevato.

ho intenzione di dire di sì, per una semplice ragione: l'iPhone. Tutti quelli che ho mai parlato pensa che sia fantastico perché l'interfaccia slick, ma posso solo immaginare il sottostante lavoro per far sì che tutto il possibile.

Dipende dal pubblico. Io lavoro con un sacco di analisti finanziari e la loro idea di un buon design gui è uno che ha il maggior numero di campi, come si può eventualmente marmellata su un unico modulo. Scherzi a parte, sto parlando 75 - 100. Sono drogati di dati che sempre vogliono di più. Recentemente ho migliorato le prestazioni su un paio di stored procedure che potrebbero prendere 45 secondi per il carico (Calcola la media ponderata dall'inizio della roba di tempo). Capito fino a 30 secondi; Sto pensando wow, tagliare un terzo del tempo; dovrebbe essere una voce sul mio curriculum. Nessuno nemmeno notato. Continuava a lavorare su di esso e ottenuto per 15-20. cambiamento notevole. Tutti erano molto felice. Penso ancora che la GUI è un abominio, e se abbiamo preso questa schifezza inutile, sarebbe caricare in 2 secondi, ma quando ci sono 15 diverse caselle di testo multi-linea (sapete quelli che hanno tutte le capacità di formattazione con le impostazioni di caratteri MAX .), è senza speranza.

utenti Quindi, se si vuole davvero ti amo, ricordate che la migliore interfaccia utente è alcuna interfaccia a tutti (vorrei ricordare che ha detto che). Dopo voler vedere tutti questi dati, i miei analisti hanno capito che sono quelli da fare tutto l'inserimento dei dati -. L'orrore

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

Ogni persona in giro si sentono competenti a dare un consiglio o per impostare una richiesta di come si dovrebbe fare.

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

Ma se sarà visto alcun errore ( alcuni accade sempre), il primo uomo a essere condannato sarà il programmatore GUI, l'utente semplicemente mai avevano visto gli altri!

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a softwareengineering.stackexchange