Il design richiede più tempo dello sviluppo del codice? [duplicare]

Quando faccio stime tradizionali, la mia esperienza è che la distribuzione degli sforzi è di circa il 30% di progettazione, 40% di implementazione, 30% di test e solitamente il design è considerato completo quando hai identificato le classi rilevanti, le loro responsabilità e opzionalmente i metodi principali .

Uno dei rischi che correte quando si esegue un progetto completo e completo è che è possibile eseguire Analisi Paralisi , il che significa che non si ottiene mai nulla, perché continui a "migliorare" il tuo design senza un chiaro vantaggio per la situazione attuale.

Quindi, c'è sicuramente un ottimo livello nella quantità di design da fare, e quella bugie ottimali intorno al punto in cui ti senti a tuo agio che il tuo progetto risponde ai requisiti pertinenti ed è sufficientemente dettagliato da fungere da guida durante l'implementazione.

In primo luogo, dipende dal tipo di progetto. È simile a qualcosa che hai già fatto, ripetutamente? Quindi la parte di codifica può essere estremamente breve. D'altra parte, se è completamente nuovo, con molte nuove funzionalità, allora probabilmente dovrai codificare molte funzionalità. (Bene, o utilizzare una libreria esistente.) Che deve essere testato. Il test di una nuova libreria è considerato parte dello sviluppo?)

In secondo luogo, qual è esattamente la tua definizione di "design" e "sviluppo"? Ad esempio, una persona disegna le classi in UML e alla fine le compila in codice. Un'altra persona crea classi in IDE e le rifiuta, ma non scrive ancora i corpi dei metodi. Il lavoro del primo sarebbe probabilmente classificato come "design" e il secondo come "sviluppo", ma stanno facendo la stessa cosa, usando solo strumenti diversi. (Una persona più filosofica potrebbe forse argomentare che tutto la codifica è design.)

In terzo luogo, probabilmente dipende dal linguaggio di programmazione, dalla metodologia utilizzata, ecc. Poco a poco - se hai fatto un errore nella fase di progettazione, sarebbe facile o difficile da notare? Perché se non lo noti nella fase di progettazione, dovrai trovarlo e risolverlo durante il periodo di sviluppo ufficiale speso.

Non penso che devi usare un "90%" come regola d'oro, usa solo ciò che è meglio per TE. Lo considererei come una linea guida per dedicare più tempo a pensare a come farlo, invece di provare per permutazione.

Pronuncia semplicemente NO a "regole d'oro", usale come indicatori, sì, non applicale mai.

Tendo a pianificare di più nei progetti, che sono simili a quelli che ho già fatto. Perché so cosa ha funzionato l'ultima volta e cosa no, quindi posso approfondire i dettagli nella pianificazione dell'architettura.

Quando faccio qualcosa di nuovo, ho una vaga idea di cosa devo fare. Ma iniziare subito a scrivere codice e buttare fuori le idee sbagliate in anticipo ha dimostrato di essere un'idea migliore che pianificare un sacco di cose e implementarle in seguito, solo per vedere che i piani erano imperfetti al primo posto.

Quindi più conosco il software che implementerò, più dedico alla pianificazione.