Un progetto software dovrebbe avere una fase di progettazione dettagliata che descriva il codice?

Sei confuso sulla differenza tra la progettazione dettagliata e la codifica.

Da un commento che hai postato:

during the detailed design. The way I see it, the Design phase would comprise 2 stages : High-level and Detailed. While "High-level" would identify the data structures and list of programs, Detailed design would spell out the logic. If the logic is stated only in words, it leaves risk at the coding level - can the logic be accurately translated into code in a timely manner? Therefore, it would be a risk-mitigation device to design the code as well.

A partire dal 2018, gli umani esperti sono ancora tenuti a creare software utile. Non lasciare che tutto il clamore di apprendimento automatico ti ingannasse, abilità umane, non processo, è ancora l'anello più importante della catena.

If the logic is stated only in words, it leaves risk at the coding level - can the logic be accurately translated into code in a timely manner?

Trasformare la logica descritta con linguaggio naturale in istruzioni logiche che una macchina può eseguire, è l'abilità fondamentale degli sviluppatori di software. Questo processo deve essere fatto da qualche parte. Questo rischio sarà presente, finché noi umani siamo nel processo. Pensi di attenuare il rischio, ma lo stai semplicemente spostando e rendendolo più costoso.

Quello che stai descrivendo qui sta trasformando i "coder" in dattilografi. Fare ciò non ti porterà alcun vantaggio, ma ti porterà costi considerevoli. Hai già realizzato alcuni dei problemi che stai invitando a te stesso. Potresti scrivere un intero programma software in MS Word, quindi consegnarlo a qualcun altro per copiarlo senza cervello in un IDE. Ma come te ne preoccupa, MS Word non esegue alcun controllo di compilazione. Nessuno degli strumenti è lì. E qual è la probabilità che tu possa scrivere un programma di migliaia di righe e farlo funzionare perfettamente alla prima prova? Abbastanza improbabile. Ora la tua dattilografa deve tornare da te e devi modificare il tuo documento MS Word, e riprovare più e più volte, con una seccatura enorme e costa ogni volta. Hai realizzato il rischio che i programmatori impiegassero troppo tempo a scrivere il codice, trasformandolo nella realtà di qualcun altro che scrive il codice, utilizzando un ambiente di sviluppo davvero fantastico, e che ha impiegato altrettanto o più a fare nulla.

Ad un certo punto ti rendi conto, dal momento che la persona che scrive il documento Word è l'unica di cui ti fidi con l'abilità fondamentale per fare la programmazione vera e propria, forse quella persona dovrebbe essere quella a digitare tutto in primo luogo nell'IDE.

Le lingue parlate in natura sono un linguaggio molto scadente per la comunicazione di argomenti super-precisi. Le lingue parlate sono incredibilmente sensibili al contesto. I linguaggi di programmazione no. Un design dettagliato è scritto idealmente nel punto giusto tra linguaggio naturale e linguaggio tecnico, con il punto su quello spettro che varia in base all'abilità degli sviluppatori e al rischio del progetto.

Il design più dettagliato di un sistema software è il codice (vedi questi saggi di Jack W. Reeves o questo articolo / discussione su Wiki C2 ). Per poter effettivamente realizzare qualsiasi tipo di software utile, è necessario eseguire una progettazione dettagliata. Quindi devi prendere l'output di questo disegno dettagliato (il codice) e trasformarlo in un prodotto software utile (compilandolo o interpretandolo).

Non ha senso scrivere codice in qualcosa di diverso da un IDE o un editor di qualche tipo. C'è un ampio spettro di buoni strumenti per scrivere codice, a seconda della piattaforma, della lingua e delle preferenze personali.

Una buona domanda sarebbe quindi quanto è necessario il design prima di scrivere il codice. E questo dipende molto dalla tua piattaforma. Dipende da cosa è e cosa fa il sistema. Mi aspetto che un'app mobile per un gioco di carte abbia un diverso livello di progettazione rispetto al software incorporato per un pacemaker o un'applicazione aziendale a cui una grande multinazionale dipende per svolgere il proprio lavoro.

Mi aspetto che qualsiasi lavoro di progettazione pre-codice possa prendere testo in chiaro, dati tabellari o dati grafici. In alcuni ambienti molto rigorosi, potrebbero essere utilizzati i metodi formali . Ma mi aspetterei che nessuno di questi si focalizzerà sui dettagli del linguaggio di programmazione o della piattaforma: questi dettagli si presenterebbero quando si eseguiva "progettazione dettagliata" (o codifica). Non mi aspetterei che il lavoro di progettazione pre-codice fosse privo di qualsiasi conoscenza del linguaggio di programmazione. Considero le decisioni come l'infrastruttura, i sistemi operativi, il linguaggio di programmazione e le strutture architettoniche come decisioni architettoniche che metterebbero vincoli su qualsiasi progetto più dettagliato richiesto in base alla natura del progetto.

Non è in linea con i lifecylce dello sviluppo moderno

La progettazione dettagliata viene utilizzata in un approccio a cascata con un modello di fase predefinito come piano, analisi, progettazione generale, progettazione dettagliata, implementazione, test e accettazione.

Questo approccio è obsoleto. I moderni approcci di sviluppo del software sono agili, con cicli iterativi in cui la progettazione dettagliata viene eseguita insieme all'implementazione, poiché sono entrambi completamente interconnessi.

La documentazione di progettazione dettagliata è rapidamente obsoleta

Indipendentemente dal ciclo di vita dello sviluppo, una volta che il codice è stato avviato, ci sarà un sacco di aggiustamenti nella progettazione, a causa di interrelazioni inaspettate, cambiamenti nei requisiti o semplicemente grandi idee di miglioramento.

Documenti di progettazione molto rapidamente dettagliati non saranno sincronizzati. Ciò non solo comporterà ulteriori sforzi di aggiornamento, ma renderà la documentazione inutile: ogni volta che sorge qualche domanda sul design dettagliato, la gente si chiederà se è aggiornata e controlla il codice.

Il codice può essere la sua documentazione?

La prima raccomandazione di Booch era di documentare nel design, cose che non possono essere facilmente comprese dal codice, come la struttura complessiva dei componenti, le relazioni tra classi, le interazioni complesse tra oggetti e così via. È inoltre possibile documentare la logica per alcune importanti decisioni di progettazione. Ma lascia che il codice documenti i dettagli (sia in codice esplicativo che in alcuni commenti aggiuntivi).

Should a Software project have a Detailed Design phase ... ?

Naturalmente.

Avere un piano è sempre meglio che non avere un piano. Che tu lo faccia effettivamente o no (e fino a che punto lo fai) dipende da molti fattori, come i limiti di tempo, la complessità del software, il livello di rigore richiesto e così via.

... in which the detailed specifications (ie, the code) are spelt out? Finding the right syntax to be used may be difficult, given the myriad language features available.

Pensare alla sintassi prima ancora di sapere cosa stai costruendo è prematuro.

Il tuo compito come sviluppatore di software è convertire i requisiti e le specifiche che ricevi in codice che soddisfi tali requisiti e specifiche. Gli stakeholder che ti forniscono queste istruzioni non sono minimamente preoccupati per quanto riguarda le funzionalità linguistiche o la sintassi che usi; è il tuo lavoro per capirlo.

Therefore, it might be best to design the code before actual coding and then review the design.

Se con ciò intendi dire distruggere una gerarchia di classi e una struttura architettonica ragionevolmente buona, certo. Se intendi la scelta di strutture di dati con le caratteristiche di performance corrette, ovviamente. Le funzionalità linguistiche giocheranno una parte in questo, perché hai bisogno di classi nella tua lingua per far sì che un diagramma di classe abbia senso. Il tuo approccio al design sarà molto diverso se la tua scelta linguistica è, ad esempio, Lisp o Haskell anziché C # o Java.

Ma a quel punto non raccogli più i requisiti degli analisti di business. Invece, ti stai incontrando con il tuo capo squadra o il responsabile tecnico per elaborare un progetto o (a seconda delle dimensioni dell'azienda) progettando il software da solo.

Should a Software project have a Detailed Design phase ... ?

No!

La realizzazione di un piano richiede molto tempo e spesso con il progetto software si scopre che i requisiti cambiano durante la pianificazione o lo sviluppo del software. Rendi il tuo piano inutile.

Per la maggior parte dei progetti software una metodologia Agile, in cui non si pianifica dettagliatamente, ma solo direttamente nelle funzionalità di sviluppo si possono ottenere risultati migliori.

O almeno avvisarti quando il tuo progetto sta fallendo prima di sostenere un costo elevato.

..what kind of medium would be good for spelling out the code?

User story e sketch approssimativi, quanto basta per comunicare una piccola funzionalità

Dalla mia esperienza sarebbe troppo. La pianificazione dovrebbe concentrarsi sul valore aziendale. Funzionalità per così dire. Quindi criteri di qualità su tali caratteristiche. Forse alcuni aspetti tecnici se sono in qualche modo risolti. Ma il "come" viene implementato verrà dopo. Nella mia esperienza, descrivere il valore del business abbastanza bene da poterlo sviluppare, testare e consegnare con successo è la più grande preoccupazione. Lascia l'implementazione agli sviluppatori.

In mischia la pianificazione specifica dell'implementazione viene eseguita nella suddivisione delle attività da parte del team poco prima dell'implementazione. In questo modo ti assicuri che la pianificazione dettagliata non sia obsoleta.

Magari avere recensioni di codice e dojo di codifica in modo che tutti gli sviluppatori siano aggiornati con ciò che la tua lingua e la struttura hanno da offrire.

Più il piano è dettagliato, maggiore è il rischio che il piano sia sbagliato. E se hai un piano prezioso su cui hai lavorato così duramente, può essere mentalmente difficile cambiarlo. Ma tu devi! I piani non funzionano come previsto, specialmente quelli grandi. (Esagerando un po 'forse. Alcuni piani funzionano, ma per lo più a breve termine)

Non fraintendermi, dovresti pianificare! E un piano più dettagliato è meglio di uno troppo semplice, a patto di rimanere agile e di adeguare il tuo piano. Tuttavia, adattare il tuo piano è anche uno sforzo!

Immagino che tutti possano vedere che sono in agile / scrum e XP ...

Ho sperimentato molti significati di pianificazione inutili. Abbiamo perso le scadenze e l'errore che abbiamo commesso è che pensavamo di dover pianificare un piano migliore, migliore e più dettagliato. Il "meglio" abbiamo pianificato più il piano era spento ...

La pianificazione continua è ciò che ci ha aiutato qui.

Basta vagabondaggio, spero di poter aiutare