I progetti "proattivi" su nuovi progetti sono utili?

1

Quando si inizia un nuovo progetto, i progetti "proattivi" sono utili? Voglio dire, se crei un diagramma UML / diagramma di attività / Usa caso / diagramma di classe / ecc. per qualsiasi cosa e ogni cosa a cui pensare, poi quando pensi hai finito, inizi a programmare. In seguito, ti rendi conto che una caratteristica importante o un metodo sono stati lasciati fuori. Tutti i tuoi spimpuri diagrammi UML sono belle pile di carta inutile ora.

È più facile / migliore progettare una classe, lavorarci un po ', perfezionarla, quindi lavorarci di più?

    
posta Casey 15.07.2011 - 07:34
fonte

5 risposte

8

Contrariamente all'opinione pubblica, non compro molto nel movimento "Big Design Up Front is bad".

Questa affermazione è usata troppo spesso come introduzione a un progetto con nessun disegno . Il progetto è iniziato senza progettazione e nessuno si materializza mai durante lo sviluppo.

Inoltre, non credo che questo modo di lavorare sia quello che intendevano i sostenitori originali (dai movimenti Extreme Programming / Agile, IIRC). Intendevano che gli sviluppatori avrebbero evoluto il loro design insieme all'implementazione in evoluzione.

Quindi credo che il processo dovrebbe essere:

  1. Crea un design quanto basta per poter iniziare il progetto. Nota: sono un deciso oppositore di "una caratteristica alla volta" - credo che dovresti iniziare con un'implementazione minima dello scheletro dall'inizio alla fine (nota anche come slice verticale). Altrimenti non stai facendo uno sviluppo iterativo ma uno sviluppo incrementale, e stai ancora correndo il rischio di avere una "integrazione big bang" quando finalmente implementerai l'ultima funzionalità per completare il ciclo del tuo progetto.
  2. Implementa il tuo primo progetto.
  3. Valuta i risultati di progettazione e implementazione. Questo dovrebbe includere il feedback dei tuoi clienti e utenti finali, quando possibile, per assicurarti di costruire la cosa giusta.
  4. Rileggi ed espandi il tuo design.
  5. Implementa il tuo design rielaborato e ampliato.
  6. Continua con 3 fino a quando non hai finito.
risposta data 15.07.2011 - 10:26
fonte
1

Ciò che chiamate "proactive design" è generalmente chiamato "big design up front" (BDUF) e considerato una pessima idea. I venditori di strumenti UML sostengono di farlo funzionare tramite MDD, cioè più o meno tutto il codice è generato direttamente dai diagrammi UML o mantenendo il modello in sincronia con le successive modifiche nel codice. Ma questo non funziona mai perfettamente e generalmente ti imbatti in più problemi di quanti ne valga la pena.

Is it easier/better to design one class, work on it a bit, refine it, then work on it more?

Una classe alla volta non sarebbe una buona idea neanche. Ma una funzione alla volta, tenendo a mente le caratteristiche future al momento di decidere il design di alto livello, sembra funzionare piuttosto bene.

I diagrammi UML (o modelli in generale) hanno il maggior valore nel fornire una panoramica di alto livello dei sistemi. Se diventano troppo dettagliati, i vantaggi (panoramica visiva) diminuiscono e la loro produzione richiede una quantità di tempo ingiustificabile.

    
risposta data 15.07.2011 - 10:18
fonte
1

alcuni design "proattivo" = > può essere utile

Completa design upfront dettagliato = > non per niente utile

    
risposta data 15.07.2011 - 16:54
fonte
1

Sicuramente non vuoi che la "caratteristica unica" combinata con qualche forma contorta di YAGNI porti a ciò che spesso accade:

"Oh, so we need to allow the customer to store 3 addresses, so I'll just add three columns to the customer table."

"Shouldn't we try to maintain a relational model with a seperate address table and a surrogate key in case at some point a customer needs 4 addresses."

"YAGNI, they are really gonna need to put in another feature request for us to allow for 4 customers. You're overengineering for a use case that doesn't exist"

"...FML"

È sempre necessaria una certa quantità di "guardare avanti". Se così non fosse, nessuno si preoccuperebbe dei modelli e delle migliori pratiche. Senza una specifica funzionale di alto livello, come dovresti dare la priorità a quale caratteristica verrà dopo. Non sono enorme su UML, a meno che non sia un abbozzo approssimativo della prima iterazione sul mio blocco note, ma la fase di progettazione deve sempre includere una sorta di descrizione funzionale di come dovrebbero comportarsi le cose. Questo potrebbe essere controindividuale, ma davvero non penso nemmeno che importi molto quello che fai con le specifiche una volta che è stato scritto (aggiornalo mentre vai, mettilo in una cartella a cui nessuno va, cancellalo, ecc. .). Il vantaggio principale del processo di progettazione e le specifiche lente sono che ti costringe a scrivere tutte le tue idee e vedere se hanno senso.

    
risposta data 15.07.2011 - 17:02
fonte
0

Di solito faccio un sacco di UML e altre forme di artefatti che pianificano come farlo, e quindi a volte lo penso troppo e implemento qualcos'altro. Questo mi lascia molti documenti (mi piace dipingere con carta e penna) e molti file sul computer.

Il mio miglior consiglio è quello di creare tutti gli artefatti di cui hai bisogno / bisogno e tenerli. Alla fine vedrai che il software sta vivendo. Prima o poi dovrai refactoring parti del tuo software, magari parti che sono ben documentate e hanno un sacco di UML. Ecco com'è. Ho trascorso un po 'di tempo a documentare parti del nostro software aziendale che stavamo usando. Dopo aver terminato alcuni diagrammi e documentazioni, abbiamo rifattorizzato la parte, lasciando tutti i miei documenti condannati.

Ad un certo punto della tua carriera o della tua vita da hobbista, ripenserai a qualche disegno di prima e che hai i documenti in giro :)

    
risposta data 15.07.2011 - 17:33
fonte

Leggi altre domande sui tag