Sappiamo tutti che il processo di creazione di un progetto e l'intera architettura del software è molto importante prima di scrivere il codice. Ma quanto deve essere approfondito il materiale del design - dovremmo iniziare dall'architettura generale e scendere ai nomi delle classi o dovremmo semplicemente designare parti comuni e iniziare la codifica?
Innanzitutto, la seguente affermazione che hai fatto non è vera.
We all know the process of creating a design and the whole architecture of the software is very important before writing the code.
Molti, e probabilmente la maggior parte dei negozi di sviluppo sono arrivati alla conclusione che fare un sacco di lavoro di progettazione non è vantaggioso. Il problema è che all'inizio del progetto, tutti (stakeholder, sviluppatori, ecc.) Conoscono l'ULTIMO che potranno mai sapere su ciò che deve essere costruito (vedi Cono di incertezza ). Non è il momento di prendere decisioni importanti scritte in pietra.
Il mio consiglio è di fare la minima quantità di design con cui puoi cavartela prima di iniziare a programmare. Dopo aver fatto qualche giro di prototipi, arricchisci i disegni con più dettagli.
Dichiarazione di non responsabilità: questo consiglio si applica principalmente agli sforzi di sviluppo in cui il problema non è ben definito in anticipo e si sente ancora molto confuso. Se sai esattamente cosa devi costruire e non c'è molta incertezza, tutto vuol dire andare più in profondità sui tuoi progetti. Detto questo, ricorda soprattutto che il tuo deliverable è un codice funzionante, non un documento di progettazione. Fai tutto il tempo necessario per completare il lavoro.
Ciò è determinato dal ciclo di vita dello sviluppo e dai vari attributi a livello di progetto e di prodotto. Non esiste un'unica risposta giusta applicabile a tutti i progetti. Alcuni progetti tendono a creare un'architettura di sistema in primo piano e quindi a entrare in una progettazione dettagliata per porzioni del sistema, iterativamente o simultaneamente. Altri progetti semplicemente progrediscono dall'architettura e perfezionano continuamente il design, che viene completato e sottoposto a baseline prima di iniziare l'implementazione. Altri progetti potrebbero non richiedere un design o un'architettura formale e le decisioni e lo stato attuale del progetto vengono acquisiti in modo informale.
Ci sono una serie di fattori che possono aiutarti a scegliere una metodologia di sviluppo, che va dalla quantità di rischio affrontata dal progetto, dalla quantità di visibilità desiderata sia dal management che dal cliente, dalla familiarità del team con il dominio e la tecnologia, la volatilità dei requisiti e così via. Il Rapid Development di Steve McConnell: Taming Wild Software Schedules ha un intero capitolo sulla scelta della metodologia appropriata.
We all know that the process of creating a design and the whole architecture of the software is very important before writing the code.
Questa è una falsa dicotomia.
Il codice è solo una progettazione dettagliata. Niente di più.
L'auspicata distinzione tra "design design" e "codice design" è la presenza di codice eseguibile.
Tuttavia, questa distinzione diventa torbida quando disponiamo di generatori UML-to-code. Se creiamo UML dettagliato, diventa il codice.
Se disponiamo di un linguaggio di progettazione formale di alto livello - una sorta di DSL che traduce in codice design o architettura di alto livello - allora DSL diventa il vero codice.
Ad esempio. Il C ++ veniva tradotto in C, che era tradotto in una forma intermedia neutrale rispetto all'architettura dalla quale alla fine fu generato "codice". Ciò significa che il C ++ potrebbe essere definito un linguaggio di progettazione di alto livello. Di certo non è molto vicino al codice.
Se usiamo un generatore GUI di alto livello e IDE per trascinare e rilasciare icone che creano codice, che cos'è? È design? Ma crea codice, vero?
Penso che la distinzione tra "design" e "codice" non sia di grande aiuto.
Che porta alla risposta alla tua domanda.
should we start from the general architecture and go down til the names of the classes or should be just designate common parts and start coding?
Dipende da ciò di cui il tuo pubblico ha bisogno. Scrivi design a un livello in modo che possano portare il design al livello successivo di dettaglio.
Hanno bisogno di lezioni?
O hanno solo bisogno di schemi di progettazione in cui riempire le classi?
O hanno bisogno dei nomi dei metodi?
Dipende dal tuo pubblico.
Ti rimanderò al Capitolo 9 del libro Programmazione Python: un'introduzione al computer Scienza di John M. Zelle, Ph.D. ha introdotto la strategia di implementazione bottom-up top-down design e afferma che il processo di analisi alla fine porta problemi di dimensioni tali da essere banali da risolvere.
Direi che dovresti applicare la stessa strategia e andare in profondità quando risolvere il problema è banale. Ma quando è banale? dipende dalle tue capacità.
Nella mia esperienza ci sono due parti in questa domanda.
Rispondi alla prima parte, quanto dettagliata dovrebbe essere l'architettura ...
L'architettura dovrebbe avere la minima quantità di dettagli che garantisce che le proprietà desiderate vengano promosse o inibite in modo appropriato dalla progettazione del sistema. I dettagli di livello inferiore possono essere rinviati ai progettisti downstream (potrebbero essere persone che scrivono codice o forse un altro utente architetto del sistema). Ricorda che come architetto, il tuo obiettivo principale è su proprietà di sistema , gli attributi di qualità chiave. A seconda della proprietà, potrebbe essere necessario progettare parti del sistema a diversi livelli di dettaglio.
Ad esempio, a seconda delle dimensioni del sistema e delle proprietà che ti interessano, per un architetto che supervisiona un progetto con molti team, preoccuparsi dei nomi delle classi è troppo basso. D'altra parte, i nomi di classe potrebbero essere considerati design di alto livello per un responsabile del team responsabile dell'implementazione di un solo pezzo del sistema. (A parte: per le piccole squadre che fanno tutto, scambierai questi cappelli ogni giorno.)
Rispondi alla seconda parte, quando dovrebbe essere specificato un livello di dettaglio un po 'più complicato ...
L'architettura di un uomo è il design dettagliato di un altro uomo - tutto dipende dalla prospettiva del sistema e dalle proprietà che si è responsabili della supervisione. L'unico aspetto del design che deve realmente accadere prima è la definizione dei confini tra elementi e livelli di astrazione. Una volta definiti chiaramente, diversi elementi possono essere progettati a diversi livelli di dettaglio, generalmente (ci sono eccezioni) contemporaneamente.
Quando un livello di dettaglio deve essere specificato può dipendere da una miriade di fattori, tra cui ...
Penso che la maggior parte delle aziende stiano adottando lo sviluppo di software Agile: link
L'idea di base è che tu:
Poi alla fine della tua iterazione di due settimane, consideri i tuoi risultati e pianifica la tua prossima iterazione. Alcuni dei vantaggi di questa metodologia sono:
Mi piacerebbe echeggiare il sentimento di S.Lott di "codice è design" e consiglio di JohnFx di "progettare il meno possibile prima di iniziare la codifica", ma esporre su perché . La ragione è semplice: scrivere codice è un processo di scoperta.
Puoi costruire castelli in aria tutto ciò che desideri, ma ci sono cose che scoprirai solo una volta che hai effettivamente scritto il codice. Ti imbatterai nella duplicazione del codice che non vedresti mai quando stavi creando una serie di diagrammi UML perché l'implementazione non è proprio lì. Potresti realizzare che un componente deve essere suddiviso in due o più parti quando provi a scrivere test unitari per questo. Inoltre, stai inseguendo un obiettivo in movimento, anche se hai la chiaroveggenza per concepire il design perfetto in primo piano, non sarà più perfetto una volta che i requisiti cambiano.
Il miglior consiglio che posso darti è seguire l'idea alla base delle metodologie agili: fare un piccolo passo verso il tuo obiettivo, dare un'occhiata al risultato e usare la tua intuizione appena trovata per correggere gli errori e correggere il tuo corso . Continua a farlo finché non hai finito. E non dimenticare di Keep It Simple, Stupid!
Leggi altre domande sui tag design architecture source-code