Può essere utile creare un'applicazione che inizia con la GUI?

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

• è molto allettante (per manager / utenti) utilizzare ulteriormente il codice prototipo e creare l'applicazione finale su di esso, il che può avere conseguenze a lungo termine molto gravi (ciò è avvenuto in uno dei progetti su cui ho lavorato, e è risultato in un prodotto "funzionante" con architettura inesistente e un sacco di problemi di manutenzione per noi)
• per l'utente medio, la GUI è l'applicazione . Quindi, una volta che vedono una GUI piacevole, tendono a credere che la maggior parte del lavoro sia fatto, quindi potrebbero essere molto turbati dal "poco lavoro rimanente" che trascina così tanto tempo: - /

Per attenuare questi rischi è necessaria una discussione attiva e possibilmente formazione dei tuoi utenti e / o gestori.

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

"Il mio fondamento logico è che, costruendo almeno una GUI prototipo, si ottiene un'idea migliore di ciò che deve accadere dietro le quinte, e così sono in una posizione migliore per iniziare a lavorare sul dominio e supportare il codice."

Questo è, a mio avviso, il modo sbagliato di guardare a un livello aziendale e un ottimo modo per trovare un design scarso e inespugnabile. Un livello dati ben progettato per esprimere completamente i dati può essere utilizzato in qualsiasi interfaccia utente. Un livello dati progettato per funzionare in base alle esigenze di un'interfaccia utente specifica potrebbe non essere adattabile a qualcos'altro, nemmeno a aggiunte di funzionalità secondarie 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 complicati. Inoltre tendono a creare un accoppiamento tra l'interfaccia utente e il livello dati che non dovrebbe mai, mai essere lì.

L'indipendenza del livello dati e il livello dell'interfaccia utente devono essere incoraggiati. Questo è il motivo per cui la creazione del livello dati per rappresentare semplicemente l'intero dato anziché mirare a una specifica interfaccia utente semplicemente funziona meglio a lungo termine.

Costruire un prototipo può essere utile per la raccolta e l'approvazione dei requisiti, ma dovrebbe essere gettato via. In realtà non utilizzare nulla dal codice prototipo nel prodotto reale.

Penso che @ Péter abbia ragione a suggerire che la creazione di prototipi di GUI sia una buona idea. Mi piacerebbe integrare con le potenziali insidie di fornire l'esperienza dell'utente in modo ass-back, cioè concentrarsi su ontologie, l'architettura e l'infrastruttura prima e l'esperienza utente immediata per ultimi:

• L'utente che hai spinto fino alla fine della cronologia dello sviluppo invalida le tue stime dei dati e il modo in cui la tua applicazione viene utilizzata.
• I tuoi elaborati progetti che hai sviluppato prematuramente si rivelano essere macchinazioni a scopo personale che hanno un utilizzo molto scarso o inutile alla fine.
• La tua applicazione potrebbe essere sottoposta a tale stato in cui la consegna di esperienze utente scadenti diventa la norma.

Fai il coraggio e poi l'utente ottiene ciò che è venuto fuori dalle tue supposizioni, mentre dovresti preoccuparti di ciò di cui l'utente ha bisogno e costruire il coraggio di conseguenza. Perché la gente ricorre a farlo viceversa è semplicemente perché la presentazione, con cui l'utente interagisce, da cui i comportamenti dell'applicazione si insinuano naturalmente, è la parte più complessa del sistema che non viene mai completamente esplorata o le persone si sentono molto bene felici di occuparsi di costruire cose per evitare di dover effettivamente pensare a perché / cosa / per chi lo stanno costruendo. Erigere un'enorme struttura strutturalmente sana è un gioco da ragazzi, far sì che soddisfare i bisogni funzionali (ed estetici) di ognuno sia la parte più difficile.

Per ogni esperienza craptastic, flusso eccentrico, informazioni scarsamente collocate, mancanza di funzionalità ovvia, cose che sono semplicemente sbagliate, casi ogni volta che hai pregato di chiedere "solo quale genio ha escogitato che ? ", si tratta di qualcosa che ha ignorato, negato o rivelato l'utente come prima linea degli sforzi di sviluppo.

Penso che sia un ottimo modo per affrontare la progettazione delle applicazioni, specialmente in un ambiente di sviluppo agile. La maggior parte dei progetti di successo su cui ho lavorato sono iniziati con un prototipo che alla fine è diventato la cosa reale.

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

Iniziando dalla GUI, il cliente ha un'idea migliore di ciò che desidera. Mentre questa fase progredisce, lo sviluppo della GUI (usando mock e stub) dà origine 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 prototipo? Non abbiamo a che fare con gli stadi costruiti con i fiammiferi. Basta ridimensionare la dannata cosa in qualcosa di buono.

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

Se ci si attiene all'utilizzo di un'architettura in stile MVC, non prevedo alcun problema di manutenzione o costruzione in futuro, in quanto la "Vista" non definisce affatto questo tipo di cose. I "Controller" e "Modello" possono venire in seguito 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 il V al 20% e spiega che il resto della torta è "TBC";).

In qualsiasi sistema di dimensioni ragionevoli, ciò che deve accadere dietro le quinte è liberamente correlato a ciò che la GUI assomiglia. La GUI fornirà solo alcuni dei requisiti. Ci sono spesso molti componenti che non hanno una GUI.

Dopo che il sistema è stato sviluppato, potrebbero essere necessarie interfacce aggiuntive (incluse nuove GUI). Comprendere e implementare i requisiti aziendali è fondamentale per il successo.

Dove progettare la GUI e altri meccanismi di input e output può aiutare a convalidare il modello. Gli attributi che non vengono mai emessi, potrebbero non essere richiesti. (Potrebbero esserci motivi per mantenerli, ma probabilmente saranno i requisiti di revisione 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 nessuna delle infrastrutture dietro. I prototipi di carta possono essere una buona opzione per convalidare il layout e il contenuto della GUI.

Non dimenticare che potrebbe essere necessario regolare l'interfaccia dopo lo sviluppo. Ho sentito la segnalazione di una sostituzione dell'interfaccia di checkout fallita per un processo di checkout in cinque fasi. Un'interfaccia molto più semplice non dava agli utenti la sensazione di sicurezza appropriata e aveva un tasso di completamento molto più basso. Ascolta Speed Bumps: l'ingrediente magico nel marketing .