Voglio scrivere il mio primo programma Java, ad esempio Phonebook, e mi chiedo cosa fare prima. La mia domanda è: dovrei scrivere prima le classi GUI o utilizzare prima le classi? Sono uno sviluppatore di database e voglio conoscere le migliori pratiche nel programma di costruzione.
In teoria, ci sono almeno cinque possibili approcci.
Inizia con i finti colpi d'interfaccia utente o un prototipo di carta. Trasformali in veri e propri dialoghi e fatti strada tra i gestori di pulsanti e altri controlli attraverso la logica e il database.
Inizia con le strutture dati (probabilmente lo schema del database). Quindi aggiungere la logica (modellando i processi del mondo reale); infine, l'interfaccia utente è solo un'interfaccia per attivare la logica e visualizzare i risultati.
Inizia con la logica del programma, implementando l'accesso ai dati e un'interfaccia utente rudimentale, se necessario. Quindi formalizza e indurisci le strutture dati e, infine, arricchisci l'interfaccia utente in modo appropriato.
Inizia con lo schema del database e l'interfaccia utente e lavora contemporaneamente verso il punto in cui si incontrano. Con questo approccio, la logica viene per ultima.
Inizia identificando la quantità minima assoluta di funzionalità che farebbe qualcosa di interessante e implementa l'intero stack (strutture dati, logica e UI) per questa parte. Potrebbe essere solo un ciclo CRUD di base con una semplice finestra di modifica per una sola entità. Quindi inizia ad aggiungere più funzionalità, implementando l'intero stack per ogni funzionalità (quindi 'orizzontale').
Ciascuno di questi ha pro e contro.
Top-down ti dà una visibilità visibile nelle prime fasi del processo e ti consente di verificare il tuo design funzionale con le parti interessate: spesso i mock-shot dicono agli utenti più di un progetto che diagrammi di flusso o muri di testo.
Bottom-up ti dà la possibilità di progettare uno schema di database solido come una roccia prima di impegnarti in qualcosa; Poiché uno schema di database è notoriamente difficile da modificare una volta rilasciato, si vuole ottenere questa parte correttamente: l'impatto della modifica di un'interfaccia utente è molto più ridotto e produce meno bug meno gravi.
La prima logica significa che puoi testare la logica prima di dedicare molto tempo al database e alla presentazione, il che è particolarmente interessante se la tua logica sarà davvero complessa.
Meet-in-the-middle combina i vantaggi di bottom-up e top-down, ma dovrai saltare avanti e indietro tra due attività e rischi di finire con una logica più complessa del necessario perché le tue due estremità non si incontrano naturalmente.
L'espansione orizzontale si sposa bene con un flusso di lavoro iterativo e ha il vantaggio aggiunto che, se la priorità è buona, avrai un'applicazione funzionante in qualsiasi momento, quindi se non prendi una scadenza, avrai un versione con meno funzioni, ma è ancora completamente funzionale, a differenza di una versione con un database completo, ma senza interfaccia utente.
Quindi, quale sceglierai dipende dal tuo stile personale e dalle circostanze.
Se sei uno sviluppatore di database, penso che dovresti iniziare con un modello di dati e creare un buon livello di astrazione in modo che sia facile definire la tua interfaccia utente (sia essa una GUI o meno).
Inizia con la parte del progetto che ritieni più interessante. Se inizi con la parte che non ti piace, potresti smettere prima di fare progressi. Il punto di partenza è soprattutto la preferenza, quindi puoi anche scegliere ciò su cui vuoi lavorare.
Personalmente, vorrei analizzare le preoccupazioni degli utenti e andare da lì. Idealmente, l'aspetto dell'applicazione che richiede la maggior parte del lavoro dovrebbe iniziare prima.
In questo scenario, focalizzerei l'attenzione sui midi dell'interfaccia utente come obiettivo principale. Il cliente ha espresso preoccupazione per il supporto di un gruppo di utenti finali diversi, soprattutto quelli con impedimenti visivi, e la distribuzione del sistema attraverso linee culturali. Pertanto, pur avendo un sistema funzionale e stabile sarà fondamentale, l'importanza di avere un'interfaccia che consentirà agli utenti di svolgere facilmente il lavoro ha la precedenza.
In questo scenario mi concentrerei sulla logica del dominio. Il cliente ha richiesto un sistema con interazioni aziendali complesse. Conserverà grandi quantità di strutture dati complesse. Così il lavoro iniziale che scopre e implementa la logica di business con l'archiviazione delle fonti di dati porterà a un progetto di successo.
Se il sistema è un progetto personale, concentrati su ciò che vuoi imparare dal progetto. Se sto provando una nuova tecnologia, cerco di concentrarmi su un piccolo picco e isolare la tecnologia stessa così posso capire meglio come funziona. Tuttavia, un progetto personale che attraversa tutte le fasi avrà il vantaggio di prepararti meglio a progetti "reali". In tal caso, delineerei alcuni dei principali obiettivi e li uso come trampolino di lancio. Se questa app della rubrica è un tuo progetto personale, ti suggerirei di utilizzare prima l'interfaccia utente. Come sviluppatore di database, presumo che tu sappia come connettere i database alla logica del dominio e approssimativamente come scrivere la logica del dominio, ma non ho esplorato le tecnologie dell'interfaccia utente; quindi lavorare sull'interfaccia utente dovrebbe avvantaggiare il tuo apprendimento più che partire dall'origine dati o dalla logica del dominio.
Inizia con il dominio o ciò che chiami "util classes". Provalo indipendentemente dall'implementazione dell'interfaccia utente. In questo modo ottieni una migliore comprensione di come la tua applicazione si comporta (o dovrebbe comportarsi), di come si sviluppa la logica indipendentemente dal framework UI, MVC o whatnot, strumenti, stili che prevedi di utilizzare alla fine.
Vincolare a una specifica implementazione dell'interfaccia utente di solito è una cattiva idea. Non sto dicendo che non dovresti prenderlo in considerazione. Sto dicendo che la tua applicazione non dovrebbe dipendere da questo. L'interfaccia utente tende a cambiare A LOT nel corso di un progetto e se il tuo dominio è legato ad esso, cambierai molto anche il tuo dominio.
Quasi tutti avranno un metodo diverso per lo sviluppo che si adatta al loro stile. Ad esempio, una persona potrebbe scoprire che è più facile progettare la GUI se hanno definito l'architettura e l'archiviazione dei dati sottostanti. Un'altra persona potrebbe tuttavia scoprire che giocare con la GUI e ottenere una bozza iniziale può aiutarli a organizzare meglio il loro sistema di storage e codificare il loro programma in modo più organizzato. Il compito prima di te sarà scoprire quale metodo (o forse qualche ibrido tra i due) funziona meglio per te. Per quanto mi riguarda, preferisco fare un primo mockup di quello che penso sarà la GUI, quindi iniziare a lavorare sui dettagli dell'applicazione. Una volta che l'ho fatto, di solito ritorna e apporto le modifiche alla GUI secondo necessità. La mia raccomandazione è di prestare particolare attenzione mentre lavori su piccoli progetti e di avere un'idea dell'approccio che ti aiuta di più.
Questo è un progetto abbastanza semplice in cui direi che non è così importante. In molti progetti, tuttavia, non sarà immediatamente chiaro esattamente come si desidera che la GUI appaia e funzioni e, una volta eseguita, qualcuno potrebbe chiederti di modificarla. È utile creare rapidamente dei mockup della GUI in modo che tu o chiunque sia in grado di prendere una decisione concreta su come dovrebbe essere e quindi questo ti aiuterà a vedere alcuni dei frammenti correlati di dati che dovrai monitorare potresti non aver notato che avevi iniziato con la progettazione dei dati.
Ancora più importante, NON vuoi che il tuo design dei dati guidi la tua interfaccia utente. Relativamente parlando, credo che correggere le scarse implementazioni della GUI sia molto più facile che correggere implementazioni di dati scadenti. Quindi voterò decisamente per iniziare con la GUI.
E io sono più un tipo di database io stesso, solo fyi.
Leggi altre domande sui tag programming-practices