Può essere utile creare un'applicazione a partire dalla GUI?

La tendenza nella progettazione e nello sviluppo delle applicazioni sembra iniziare con le "viscere": il dominio, quindi l'accesso ai dati, quindi l'infrastruttura, ecc. La GUI sembra di solito venire più avanti nel processo. Mi chiedo se potrebbe mai essere utile costruire prima la GUI ...

La mia logica è che costruendo almeno un prototipo di interfaccia grafica, si ottiene un'idea migliore di ciò che deve accadere dietro le quinte e quindi si è in una posizione migliore per iniziare a lavorare sul dominio e supportare il codice.

Vedo un problema con questa pratica in quanto se il codice di supporto non è ancora stato scritto, non ci sarà molto da fare per il livello della GUI. Forse la costruzione di oggetti simulati o classi usa e getta (un po 'come avviene nei test unitari) fornirebbe una base sufficiente per costruire inizialmente la GUI.

Potrebbe essere un'idea fattibile per un vero progetto? Forse potremmo aggiungere GDD (GUI Driven Development) all'acronimo stabile ...

Costruire prototipi di GUI veloci è una buona idea e ho sentito che viene utilizzato in molti progetti. Il feedback iniziale è davvero prezioso. Tuttavia, ha i suoi pericoli:

• è molto allettante (per manager / utenti) utilizzare ulteriormente il prototipo di codice e costruire l'applicazione finale su di esso, il che può avere conseguenze molto gravi a lungo termine (ciò è effettivamente accaduto in uno dei progetti su cui ho lavorato, e ha portato a un prodotto "funzionante" con architettura inesistente e un sacco di mal di testa di manutenzione per noi)
• per l'utente medio, la GUI è l'applicazione . Quindi, una volta che vedono una bella interfaccia grafica, tendono a credere che la maggior parte del lavoro reale sia fatto, quindi possono arrabbiarsi molto con il "piccolo lavoro rimanente" che si trascina così a lungo: - /

La mitigazione di questi rischi richiede una discussione attiva e possibilmente la formazione dei tuoi utenti e / o manager.

Il problema che vedo è che l'obiettivo sembra essere totalmente arretrato.

"La mia logica è che costruendo almeno un prototipo di interfaccia grafica, si ottiene un'idea migliore di ciò che deve accadere dietro le quinte, e quindi si trovano in una posizione migliore per iniziare a lavorare sul dominio e sul codice di supporto."

Questo è, a mio avviso, il modo sbagliato di guardare a un livello aziendale e un ottimo modo per trovare un design scadente e inespandibile. Un livello dati che è ben progettato per esprimere completamente i dati può essere utilizzato in qualsiasi interfaccia utente. Un livello dati progettato per funzionare per le esigenze di un'interfaccia utente specifica potrebbe non essere adattabile a nient'altro, nemmeno a piccole aggiunte di funzionalità a quell'interfaccia utente.

L'esperienza con i sistemi progettati nel modo in cui stai parlando mi porta a concludere che la maggior parte dei progetti che utilizzano questa metodologia finiscono per essere di breve durata e / o troppo complicati. Inoltre, tendono a creare un accoppiamento tra l'interfaccia utente e il livello dati che non dovrebbe mai, mai esistere.

L'indipendenza del livello dati e dell'interfaccia utente deve essere incoraggiata. Questo è il motivo per cui la creazione del livello dati per rappresentare semplicemente tutti i dati anziché indirizzare un'interfaccia utente specifica semplicemente funziona meglio a lungo termine.

La costruzione di un prototipo può essere utile per la raccolta e l'accordo dei requisiti, ma dovrebbe essere eliminata. In realtà non utilizzare nulla dal codice prototipo nel prodotto reale.

Penso che @ Péter abbia ragione nel suggerire che costruire prototipi di GUI sia una buona idea. Vorrei integrare le potenziali insidie ​​di fornire l'esperienza dell'utente in modo arretrato, ovvero concentrarsi prima sulle ontologie, sull'architettura e sull'infrastruttura e sull'esperienza immediata dell'utente:

• L'utente che hai spinto fino alla fine della sequenza temporale di sviluppo invalida le tue stime dei dati e il modo in cui l'applicazione viene utilizzata.
• I tuoi elaborati progetti che hai sviluppato prematuramente si dimostrano macchinazioni auto-intenzionali che alla fine hanno poco o nulla.
• L'applicazione può essere portata in tale stato in cui la fornitura di esperienze utente scadenti diventa la norma.

Fai il coraggio e poi l'utente ottiene ciò che è uscito dai tuoi presupposti, mentre dovresti preoccuparti di ciò di cui l'utente ha bisogno e costruire l'intestino di conseguenza. Perché le persone ricorrono a farlo al contrario è semplicemente perché la presentazione, ciò con cui l'utente interagisce, da cui i comportamenti dell'applicazione si diffondono naturalmente, è la parte più complessa del sistema che non viene mai esplorata completamente o le persone si sentono solo molto felici di preoccuparsi di costruire cose per evitare di dover riflettere sul perché / cosa / per chi lo stanno costruendo. Costruire un'enorme struttura strutturalmente solida è un gioco da ragazzi, riuscire a soddisfare le esigenze funzionali (ed estetiche) di tutti è la parte più difficile.

Per ogni esperienza craptastic, flusso eccentrico, informazioni scarsamente collocate, mancanza di funzionalità ovvia, cose che sono semplicemente sbagliate, casi in cui hai chiesto di chiedere "solo quale genio è venuto fuori con quello ?", C'è qualcosa che ha ignorato, negato o ha rivelato l'utente come in prima linea negli sforzi di sviluppo.

In generale, il modello dovrebbe essere sviluppato prima della vista. Una volta che hai una base logica della tua applicazione, puoi costruire una o più viste di quel modello (ad esempio, puoi visualizzare i dati nella tabella o nel grafico). Di solito, il modello è più importante della GUI. Ciò è particolarmente vero per lo sviluppo aziendale in cui la GUI viene generalmente eseguita in modo standard.

Tuttavia, a volte la GUI è davvero la parte più importante dell'applicazione. A volte vuoi guardare un dato in un modo nuovo e specifico - e lo prendi da lì, e quindi sviluppi il modello. Ad esempio, CashCurve è una tale applicazione in cui il punto è nella GUI, mentre lo stesso modello di dati è roba noiosa standard che chiunque può modellare in pochi minuti. (Dichiarazione di non responsabilità: non sono affiliato con CashCurve, solo un utente molto soddisfatto.)

Ciò è rilevante anche per la progettazione di servizi Web o di altre API - solo lì è noto come " contratto per primo" design " ".

Quindi, come per tutto, non esiste una regola su cosa progettare per primo; a volte è un modello, a volte è una GUI. Come regola generale, preferirei "progettare innanzitutto la parte più importante".

Ci sono alcuni avvertimenti da considerare quando si progetta prima la GUI, come ad esempio che l'utente avrà probabilmente difficoltà a capire che l'applicazione è lungi dall'essere completa quando esiste solo un prototipo di GUI, ma altre risposte lo hanno coperto abbastanza bene, quindi non entrerò nei dettagli.

Penso che sia un ottimo modo di approcciare il design delle applicazioni, soprattutto in un ambiente di sviluppo agile. La maggior parte dei progetti di successo a cui ho lavorato sono iniziati con un prototipo che alla fine è diventato la cosa reale.

Devi capire che la GUI è la finestra sul sistema (es. Database, filesystem, ecc.). In una situazione in cui i requisiti del progetto sono vaghi come un mucchio di fanghiglia, non avrai una speranza all'inferno di ottenere una soluzione corretta iniziando dal back-end. Quasi sempre, lo sviluppatore di backend ben intenzionato sviluppa un gruppo di API che non ha alcuna rilevanza per le interazioni dell'utente.

Avviando la GUI, il cliente ottiene un'idea migliore di ciò che desidera. Man mano che questa fase avanza, lo sviluppo della GUI (usando mock e stub) dà vita a un modello di dominio. Questo modello di dominio può quindi essere trasferito al back-end e gli sviluppatori back-end possono iniziare a sviluppare la persistenza e la logica transazionale.

E perché vorresti buttare via il protoipo? Non abbiamo a che fare con stadi costruiti con fiammiferi. Riflettete la dannata cosa in qualcosa di buono.

Non mi suona affatto male se la persona che guarda la GUI capisce che è solo una shell e letteralmente pulsanti e processi non funzionano (lanciare nuovo NotImplementedException ();;)).

Se ti attieni all'utilizzo di un'architettura in stile MVC, non prevedo futuri problemi di manutenzione o costruzione poiché la "Vista" non definisce affatto quel tipo di cose. I "controller" e il "modello" possono venire successivamente con qualsiasi infrastruttura richiesta per esigenze di scalabilità / progettazione ecc.

Per quanto riguarda la gestione, disegna loro un grande grafico a torta con 3 porzioni, etichettali "M", "V" e "C". Dai alla V circa il 20% e spiega che il resto della torta è "TBC";).

In qualsiasi sistema di dimensioni ragionevoli, ciò che deve accadere dietro le quinte è vagamente correlato a come appare la GUI. La GUI ti fornirà solo alcuni dei requisiti. Esistono spesso molti componenti che non dispongono di una GUI.

Dopo lo sviluppo del sistema potrebbero essere necessarie interfacce aggiuntive (incluse nuove GUI). La comprensione e l'implementazione dei requisiti aziendali è fondamentale affinché ciò abbia successo.

Laddove la progettazione della GUI e altri meccanismi di input e output possono essere d'aiuto è la validazione del modello. Gli attributi che non vengono mai emessi, potrebbero non essere richiesti. (Potrebbero esserci motivi per mantenerli, ma probabilmente saranno requisiti di controllo o di regolamentazione.)

Come altri hanno già detto, una volta che hai una GUI funzionante, molti clienti penseranno che hai finito. Tuttavia, potresti non avere alcuna infrastruttura dietro di essa. I prototipi di carta possono essere una buona opzione per convalidare il layout e il contenuto della GUI.

Non trascurare il fatto che potrebbe essere necessario regolare l'interfaccia dopo lo sviluppo. Ho sentito la notizia di una sostituzione dell'interfaccia di checkout non riuscita per un processo di checkout in cinque passaggi. Un'interfaccia molto più semplice non ha dato agli utenti la sensazione di sicurezza appropriata e ha avuto un tasso di completamento molto più basso. Ascolta gli Speed ​​Bump: l'ingrediente magico nel marketing .