Come si inizia a progettare un sistema di grandi dimensioni?[Chiuso]

Question

Mi è stato detto che sarò l'unico sviluppatore dietro un nuovo grande sistema.Tra le altre cose progetterò un'interfaccia utente e uno schema di database.

Sono sicuro che riceverò qualche consiglio, ma mi piacerebbe riuscire a stupirli.Cosa posso fare nel frattempo per prepararmi e cosa dovrò tenere a mente quando mi siedo al computer con le specifiche?

Alcune cose da tenere a mente:Sono uno studente universitario al mio primo vero lavoro di programmazione.Utilizzerò Java.Abbiamo già configurato SCM con test automatizzati, ecc... quindi gli strumenti non sono un problema.

Answer 1

Sai molto di OOP?In tal caso, esamina Spring e Hibernate per mantenere la tua implementazione pulita e ortogonale.Se lo capisci, dovresti trovare TDD un buon modo per mantenere il tuo progetto compatto e snello, soprattutto perché hai "test automatizzati" attivi e funzionanti.

AGGIORNAMENTO:Guardando la prima serie di risposte, non potrei essere più in disaccordo.In particolare nello spazio Java, dovresti trovare molti mentori/risorse per elaborare la tua applicazione con oggetti, non un approccio incentrato sul database.La progettazione del database è in genere il primo passo per gli utenti Microsoft (cosa che faccio quotidianamente, ma sono in un programma di ripristino, ehm, Alt.Net).Se mantieni l'attenzione su ciò che devi consegnare a un cliente e lasci che il tuo ORM capisca come persistere i tuoi oggetti, il tuo design dovrebbe essere migliore.

Answer 2

Sembra molto simile al mio primo lavoro.Appena uscito dall'università, mi è stato chiesto di progettare il database e il livello della logica aziendale, mentre altre persone si sarebbero occupate dell'interfaccia utente.Nel frattempo il capo guardava alle mie spalle, non volendo lasciare andare quello che era il suo bambino e ora era mio, e ci infilava il dito.Tre anni dopo, gli sviluppatori stavano abbandonando l'azienda e mancavano ancora X mesi alla vendita vera e propria di qualcosa.

Il grande errore è stato essere troppo ambiziosi.Se questo è il tuo primo lavoro, tu Volere commetti errori e tu Volere devi cambiare il modo in cui funzionano le cose molto tempo dopo averle scritte.Avevamo tutti i tipi di funzionalità che rendevano il sistema più complicato del necessario, sia a livello di database che di API che presentava ad altri sviluppatori.Alla fine, il tutto era semplicemente troppo complicato per essere supportato tutto in una volta ed è semplicemente morto.

Quindi il mio consiglio:

1. Se non sei sicuro di intraprendere un lavoro così grande da solo, non farlo.Dillo ai tuoi datori di lavoro e chiedi loro di trovare o assumere qualcuno con cui lavorare e che possa aiutarti.Se è necessario aggiungere persone al progetto, ciò dovrebbe essere fatto all'inizio piuttosto che dopo che le cose iniziano ad andare storte.

2. Pensa molto attentamente allo scopo del prodotto e riducilo al più semplice insieme di requisiti a cui puoi pensare.Se le persone che ti forniscono le specifiche non sono tecniche, prova a vedere oltre ciò che hanno scritto per vedere cosa funzionerà effettivamente e farà soldi.Parla con clienti e venditori e comprendi il mercato.

3. Non c'è vergogna nell'ammettere di avere torto.Se risulta che l'intero sistema deve essere riscritto perché hai commesso qualche errore nella prima versione, allora è meglio ammetterlo il prima possibile in modo da poterlo fare.Di conseguenza, non provare a creare un'architettura in grado di anticipare ogni possibile contingenza nella tua prima versione, perché non sai cosa sia ogni contingenza e semplicemente sbaglierai.Scrivi una volta con l'obiettivo di buttarlo via e ricominciare da capo: potresti non doverlo fare, la prima versione potrebbe andare bene, ma ammettilo se lo fai.

Answer 3

Inoltre non sono d'accordo sull'iniziare con il database.Il DB è semplicemente un artefatto del modo in cui i tuoi oggetti aziendali vengono persistenti.Non conosco un equivalente in Java, ma .Net ha strumenti eccezionali come Subsonico che consentono alla progettazione del DB di rimanere fluida durante l'iterazione della progettazione degli oggetti di business.Direi innanzitutto (anche prima di decidere quali tecnologie introdurre) concentrarsi sul processo e identificare i nomi e i verbi...quindi costruire da quelle astrazioni.Ehi, funziona davvero nel "mondo reale", proprio come ti ha insegnato OOP 101!

Answer 4

Prima di iniziare a scrivere codice, pianifica lo schema del tuo database: tutto il resto deriverà da quello.Ottenere il database ragionevolmente corretto fin dall'inizio ti farà risparmiare tempo e mal di testa in seguito.

Answer 5

La cosa principale è riuscire ad astrarre la complessità del sistema in modo da non impantanarsi non appena si inizia.

• Per prima cosa leggi le specifiche come una storia (sfogliandola).Non fermarti ad ogni esigenza per analizzarla lì e poi.Questo ti permetterà di avere un quadro generale del sistema senza troppi dettagli.A questo punto inizierai ad identificare i principali componenti funzionali del sistema.Inizia a metterli giù (usa uno strumento di mappa mentale se vuoi).

• Quindi prendi ciascun componente e inizia a farlo esplodere (e collegando ogni dettaglio ai requisiti nel documento delle specifiche).Fallo per tutti i componenti, finché non avrai coperto tutti i requisiti.

• Ora dovresti iniziare a esaminare le relazioni tra i componenti e se ci sono ripetizioni di caratteristiche o funzioni tra i vari componenti (che puoi quindi estrarre per creare componenti di utilità o simili).In questo momento avresti una buona mappa dettagliata delle tue esigenze nella tua mente.

• ORA, dovresti pensare a progettare il database, i diagrammi ER, la progettazione delle classi, i DFD, la distribuzione, ecc.

Il problema se si esegue prima l'ultimo passaggio è che si rischia di impantanarsi nella complessità del sistema senza prima averne realmente acquisito una comprensione generale.

Answer 6

Lo faccio al contrario.Trovo che farlo prima con lo schema del database blocca il sistema in una progettazione basata sui dati che è difficile da astrarre dalla persistenza.Proviamo prima a progettare modelli di dominio poi basare lo schema del database su quelli.

E poi c'è la progettazione dell'infrastruttura:il team dovrebbe innanzitutto stabilire delle convenzioni su come strutturare il programma.Quindi lavoriamo insieme per concordare innanzitutto un progetto per la funzionalità comune del sistema (ad esempio, cose di cui tutti hanno bisogno come persistenza, registrazione, ecc.).Questo diventa il quadro del sistema.

Ci lavoriamo tutti insieme prima di dividere tra di noi il resto delle funzionalità.

Answer 7

In base alla mia esperienza, le applicazioni Java (anche .NET) che considerano il database per ultimo hanno molte probabilità di funzionare male se inserite in un ambiente aziendale.Devi pensare davvero al tuo pubblico.Non hai detto se fosse un'app web o meno.In ogni caso, l'infrastruttura su cui stai implementando è importante quando consideri come gestisci i tuoi dati.

Indipendentemente dalla metodologia che consideri, il modo in cui ottieni e salvi i tuoi dati e il relativo impatto sulle prestazioni dovrebbero essere una delle tue priorità n. 1.

Answer 8

Suggerirei di pensare a come verrà utilizzata questa applicazione.Come lavoreranno i futuri utenti?Sono sicuro che tu sappia almeno alcune cose su ciò che questa applicazione deve gestire, ma il mio primo consiglio è "pensa all'utente e a ciò di cui ha bisogno".

Disegnalo su carta comune, pensando a dove dividere il codice.Ricorda di non mescolare la logica con il codice della GUI (errore comune).In questo modo sarai pronto per estendere la portata delle tue applicazioni in futuro a servlet e/o applet o qualunque piattaforma si presenti.Sezione in strati in modo da poter rispondere più rapidamente a grandi cambiamenti senza ricostruire tutto.I livelli non dovrebbero vedere altri livelli oltre a quelli vicini più vicini.

Inizia con la vera funzionalità di base.Tutto quel dispendio di tempo (che farà ritardare il tuo progetto di 4 settimane), non avrà molta importanza per la maggior parte degli utenti.Può essere aggiunto in seguito una volta che sei sicuro di poter consegnare in tempo.

A proposito.Anche se questo non ha nulla a che fare con il design, vorrei solo dire che non consegnerai in tempo.Fai una stima realistica del consumo di tempo e poi raddoppialo :-) Presumo qui che non sarai solo in questo progetto e che le persone andranno e verranno man mano che il progetto avanza.Potrebbe essere necessario formare le persone a metà del progetto, le persone vanno in vacanza/hanno bisogno di un intervento chirurgico, ecc.

Answer 9

Dividere il grande sistema in pezzi più piccoli.E non pensare che sia così complesso, perché di solito non lo è.Pensare in modo troppo complesso rovina solo i tuoi pensieri e alla fine il design.Ad un certo punto ti rendi conto che potresti fare la stessa cosa più facilmente e poi la riprogetta.

Almeno questo è stato il mio grave errore nella progettazione.

Mantienilo semplice!

Answer 10

Ho trovato idee molto penetranti sull'avvio di un nuovo grande progetto, basato su

• buone pratiche comuni
• Sviluppo guidato dai test
• e approccio pragmatico

nel libro Crescita del software orientato agli oggetti, guidato dai test.

È ancora in fase di sviluppo, ma i primi 3 capitoli potrebbero essere ciò che stai cercando e, secondo me, vale la pena leggerli.