La necessità di specifiche di progettazione software è diminuita significativamente con l'evoluzione di linguaggi di programmazione più espressivi?

16

Per molte persone IT, incluso me stesso qualche anno fa, il processo di sviluppo software ideale prevede la creazione di documenti di progettazione dettagliati con molti diagrammi UML prima che venga scritta una riga di codice. (Questa sembra una descrizione del modello a cascata, ma è la stessa con agile, tranne per il fatto che le iterazioni sono più piccole.)

Negli ultimi due o tre anni, ho completamente cambiato idea. Penso ancora che una specifica dettagliata dei requisiti con i casi di test associati sia assolutamente essenziale. Per progetti di grandi dimensioni, richiederei anche una descrizione generale dell'architettura prima di iniziare a programmare. Ma tutto il resto dovrebbe essere fatto nel codice il più possibile. Nel caso ideale non dovrebbe esserci una descrizione della progettazione del software tranne il codice stesso.

Come sono arrivato a questa conclusione? Ecco alcuni argomenti:

Risposta

Gli strumenti per scrivere documenti o creare diagrammi forniscono un feedback scarso. Sì, esistono strumenti di modellazione che eseguono alcuni controlli di coerenza sui diagrammi UML ma sono limitati e comportano un sacco di costi generali.

Senza feedback è difficile riconoscere e correggere gli errori.

Non appena scrivi il codice, ricevi molti feedback, ad esempio:

Errori e avvisi dal compilatore
Risultati dell'analisi del codice statico
Test unitari

Gli errori possono essere rapidamente riconosciuti e corretti.

Consistenza

Per assicurarti che il codice sia coerente con i tuoi documenti devi controllare ancora e ancora. Se ci sono cambiamenti frequenti, è difficile mantenere sincronizzati codice e documenti.

refactoring

Esistono potenti strumenti e tecniche per il refactoring del codice, mentre il refactoring delle descrizioni o dei diagrammi testuali è solitamente difficile e soggetto a errori.

C'è un presupposto per farlo funzionare: il codice deve essere abbastanza facile da leggere e capire. Questo probabilmente non può essere raggiunto con Assembler, Basic o Fortran ma i linguaggi moderni (e le librerie) sono molto più espressivi.

Quindi, se i miei argomenti sono validi, dovrebbe esserci una tendenza verso specifiche o documentazione di progettazione software meno o più leggere. Esistono prove empiriche per questa tendenza?

— Frank Puffer
fonte

2

Il design iniziale ha perso il favore a causa dello sviluppo agile che sta guadagnando popolarità man mano che l'industria matura. Le lingue che diventano più espressive e gli strumenti che ottengono un peso ridotto hanno reso più semplice la prototipazione rapida, consentendo uno sviluppo più agile. Penso che ci sia qualche causalità tra i due.

— Ripristina Monica

14

Per la mia esperienza, "la creazione di documenti di progettazione dettagliati con molti diagrammi UML prima che una riga di codice venga scritta" non è mai stata una buona idea - almeno non nel tempo da quando lavoravo come programmatore professionista, che è più di uno decennio in più di UML. Cercare un progetto di alto livello prima della codifica, tuttavia, è ed è stata una buona idea quando ci si aspetta che i sistemi abbiano una certa dimensione. Ma UML è IMHO non lo strumento giusto per questo.

— Doc Brown,

2

Troppo pigro per una risposta adeguata: linguaggi di programmazione più espressivi e computer più potenti portano alla necessità di programmi sempre più capaci e complessi, che riporta a specifiche dei requisiti più complicate.

— whatsisname

2

Letture consigliate: battere le medie .

— Robert Harvey,

1

Ho lavorato su un progetto con un design UML completo. Da cui abbiamo generato il codice. Sono giunto alla conclusione che non avrei mai più voluto farlo. È stato molto più difficile cambiare UML che cambiare il codice; e un grande modello UML è ingombrante almeno quanto un sacco di codice sorgente. Il codice "generato" era difficile da leggere e il generatore ha lasciato "marcatori" nel codice.

— Nick Keighley,

9

Metto in dubbio la premessa che le lingue sono sempre più espressive. Con il codice ASP.NET di oggi in c #, scrivo all'incirca allo stesso livello di quando ho scritto il codice ASP in Visual Basic. Usiamo ancora c ++. Javascript ha aggiunto funzionalità ma nel complesso la lingua non è cambiata. Lo stesso con SQL.

Penso che questi altri cambiamenti siano più significativi:

Adozione di test unitari automatizzati. Alcuni direbbero che i test sono le specifiche. Quindi non abbiamo rimosso la necessità di scrivere specifiche; piuttosto, li scriviamo nel codice piuttosto che nei documenti di Word.
Cambiamenti nella metodologia di implementazione. In passato era molto costoso commettere un errore perché era necessario spedire una copia aggiornata del software. Quindi dovevi stare attento. Con le applicazioni basate sul Web, è possibile distribuire correzioni per un utilizzo immediato e permettersi di reagire ai problemi anziché anticiparli, ristrutturando il codice mentre si procede.
Adozione di modelli di progettazione. Quando tutti conoscono i modelli, difficilmente devi progettare nulla; puoi semplicemente dire "aggiungi un repository factory" e il tuo team dovrebbe farlo senza la necessità di vedere UML.
Contratti di dati SOA. Praticamente tutto è SOA in questi giorni. Tutto ciò che serve è un WSDL. I giorni della definizione e della documentazione dei formati di trasferimento dei dati sono passati. L'attuale spostamento verso RESTful e micro-servizi continua questa tendenza.
I software sono più piccoli. In parte a causa delle architetture SOA, i team stanno scrivendo programmi più piccoli che sono legati insieme. Ogni singolo componente è meno complesso e richiede un design meno frontale; inoltre, è più semplice modificare parte dell'architettura senza interrompere la soluzione complessiva a causa delle interruzioni di incendio forzate dalle definizioni dell'interfaccia tra i componenti.
Molto, molto più uso di librerie affermate. Il CLR .NET offre moltissime funzionalità immediatamente disponibili, quindi non è necessario progettare, per esempio, uno schema per la memorizzazione nella cache dei dati della sessione. Le librerie di terze parti come l'interfaccia utente jQuery o Bootstrap stabiliscono standard per la scrittura del codice in modo che funzionino in un determinato modo. Non è necessario documentarli; i team dovrebbero essere in grado di usarli.
Maturità del settore. Gli SWE hanno imparato che non esiste un progetto "Battlestar Galactica" in cui passi anni e anni a cercare di raggiungere un obiettivo specifico; quando passeranno quegli anni, l'obiettivo sarà cambiato. Oggi sappiamo che il time-to-market è molto più importante che ottenere tutto esattamente come lo vogliamo nella progettazione.
Ingegneri con una formazione migliore e più coerente. In questi giorni puoi assumere ingegneri che comprendono le migliori pratiche (si spera) e le implementeranno senza un documento di progettazione che dica loro cosa fare.
Strumenti di produttività come TFS consentono di scrivere un'attività semplice che fa riferimento a un caso d'uso e fornisce un paio di punti elenco per eventuali decisioni tecniche ambigue. Non hai bisogno di molto di più. Gli sviluppatori sono in grado di rivedere, stimare, ottenere revisioni del codice, effettuare il check-in, ecc. Tutto tramite lo strumento. Questo è molto più efficiente del lavorare con documenti esterni poiché lega tutto insieme.

Hai ancora bisogno di documenti di progettazione per alcune cose ... ad esempio, se la tua applicazione è suddivisa in diversi componenti sviluppati da diversi team, devi almeno dire loro quale componente è responsabile di quali requisiti. Ma per la maggior parte, le metodologie di sviluppo odierne consentono molta più libertà offrendo allo stesso tempo strumenti per gestire e contenere tutti i rischi che potrebbero sorgere da uno sviluppatore che prende una decisione sbagliata.

— John Wu
fonte

3

La nostra industria è maturata ... un po '. L'articolo 5 è di gran lunga il cambiamento più importante; ha un impatto positivo su tutti gli altri. Ma il fatto che cambiamo su tutte le nostre tecnologie ogni 5 anni suggerisce che abbiamo ancora molta strada da fare, e l'espressività del linguaggio (l'unica cosa che è relativamente stabile nel tempo perché un significativo miglioramento in quell'area è così faticosamente difficile) produce più guadagni di quanto tu gli dia credito.

— Robert Harvey,

1

Non sono tutti progressi: il vantaggio principale è stato, con grazia, l'invenzione del compilatore. Ma insegniamo ancora diagrammi di flusso, un'astrazione sul codice assembler (e molte altre pratiche obsolete). Probabilmente perché abbiamo dimenticato il perché?

— ctrl-alt-delor

6

Direi di no .

Per una semplice ragione

Per molte persone IT, incluso me stesso qualche anno fa, il processo di sviluppo software ideale prevede la creazione di documenti di progettazione dettagliati con molti diagrammi UML prima che venga scritta una riga di codice.

Non è mai stato considerato "ideale", in quanto Extreme Programming esiste dagli anni '90 . E come dici tu:

Nel caso ideale non dovrebbe esserci una descrizione della progettazione del software tranne il codice stesso.

È stato discusso per secoli fa. Ad esempio questo leggendario articolo del 1992: What is Software Design .

Quanto sopra mostra che è possibile avere un processo "estremo" con un'architettura altamente evolutiva e un approccio iterativo senza la necessità di linguaggi o IDE complessi.

Invece, direi che questo passaggio "apparente" dalla progettazione iniziale con molti diagrammi e l'uso dei documenti del caso a un approccio più evolutivo e iterativo è semplicemente la sostituzione dei manager della "vecchia scuola" con quelli nuovi, cresciuti in molti più ambiente dinamico e per chi è molto più facile accettare e lavorare in un ambiente più "agile".

— Euforico
fonte

6

Sono praticamente d'accordo con questo, ma penso che sia iniziato molto prima di quanto sembri. Penso anche che ci sia un altro grande fattore oltre all'espressività. Quando mio padre iniziò a programmare, dovette creare schede perforate e programmare il tempo sul computer. Potresti avere una possibilità al giorno per eseguire il tuo programma. Non c'è stato molto tempo per perdere il codice di costruzione, lasciarlo fallire e quindi risolverlo. Hai avuto forse 2 o 3 colpi e se non funzionava, eri nei guai.

Il rischio di ciò ha comportato la necessità di dedicare molto tempo extra alla pianificazione del programma. Le persone scrivevano il loro codice a matita e poi lo trasferivano sulle schede perforate. Man mano che la tecnologia progrediva, potevi programmare direttamente nel terminale ma stavi ancora utilizzando risorse condivise e la CPU era costosa. Una metodologia test-first sarebbe completamente insostenibile in quel mondo. Se non avessi pianificato in anticipo, i tuoi colleghi sarebbero alla tua scrivania con forconi.

Le risorse informatiche sono diventate più economiche e migliori a un ritmo incredibile. Molti dei vincoli in base ai quali sono state sviluppate tutte queste pratiche sono stati completamente cancellati. Come sottolinea Euforico, l'allontanamento da questo è iniziato davvero negli anni '90. La continuazione di gran parte del grande design iniziale è stata pura inerzia.

Quindi, sì, la migliore espressività dei linguaggi di programmazione ha avuto un impatto su questo dal semplice fatto che è più facile usare il codice espressivo come la propria documentazione. Il costo di produzione di un documento che ti dice cosa dice il codice è molto alto e ha un valore (è inevitabilmente sbagliato a un certo livello.) Allo stesso tempo, il costo di gettare merda contro il muro e vedere ciò che si attacca è sostanzialmente trascurabile.

— JimmyJames
fonte

3

Penso che tu abbia dimenticato lo scopo di avere i documenti di progettazione in primo luogo!

I documenti di progettazione (requisiti, casi d'uso, modelli ecc.) Ci consentono di descrivere, comprendere e discutere il sistema ad alto livello. La quantità di dettagli lasciata fuori da tali documenti è ciò che li rende utili.

Non v'è alcuna necessità di disporre di documenti che descrivono l'esatto comportamento del sistema del sistema in tutte le dettagli, dal momento che in effetti il codice sorgente per sé serve a questo scopo.

Lo sviluppo del software potrebbe essere considerato il processo di trasformazione di specifiche leggibili per l'utente di alto livello in specifiche non ambigue di basso livello eseguibili da una macchina. Ma hai bisogno di input per questo processo.

— JacquesB
fonte

È assolutamente necessaria una documentazione di alto livello che non tratta i dettagli. Ma è esattamente quello che mi aspetto da un buon linguaggio di programmazione. Dovrebbe consentire di scrivere codice a diversi livelli di dettaglio. Il codice non deve essere un disordine non strutturato di istruzioni di basso livello.

— Frank Puffer,

@FrankPuffer un diagramma vale 100.000 LoC.

— RubberDuck,

1

@RubberDuck Mi viene in mente che la capacità (o la sua mancanza) di generare vari diagrammi utili dal codice potrebbe essere una misura dell'espressività di un linguaggio. Non esiste un diagramma che puoi disegnare che non possa essere espresso in una sorta di linguaggio. La domanda è se quella lingua può trasmettere le stesse informazioni in un modo che può essere facilmente scritto o letto.

— JimmyJames,

1

@RubberDuck: i diagrammi hanno senso in alcuni casi, ad esempio per spiegare l'architettura generale. Ma non penso che dovrebbero essere i valori predefiniti. Esistono sicuramente diagrammi utili e utili, ma sfortunatamente la maggior parte degli UML che ho visto è più confusa che utile. E quel che è peggio, spesso differisce dall'attuazione effettiva.

— Frank Puffer,

Mi piace che menzioni la generazione di diagrammi @JimmyJames. Preferisco la generazione alla creazione manuale. Hai un punto molto valido, ma mi chiedo se sia una funzione di espressività o di strumenti.

— RubberDuck,

1

Nel caso ideale non dovrebbe esserci una descrizione della progettazione del software tranne il codice stesso.

Questo è più lontano di quanto tu implichi. Anche cose come i tipi dipendenti (che, come ho capito, sono abbastanza promettenti in teoria) sono diversi anni.

La verifica formale è piuttosto difficile, e per questo motivo l'unico luogo in cui la verifica formale è comunemente usata sono le librerie di crittografia.

Test unitari

Se i test di proprietà non hanno raggiunto il mainstream, non credo che questo sarà pratico per molto tempo.

Inoltre, scrivere buoni test (che non dovranno essere modificati con tutti i refactor ma colpirà comunque abbastanza errori) è abbastanza difficile.

Per assicurarti che il codice sia coerente con i tuoi documenti devi controllare ancora e ancora. Se ci sono cambiamenti frequenti, è difficile mantenere sincronizzati codice e documenti.

Probabilmente al momento è più semplice utilizzare uno strumento di test della documentazione.

C'è un prerequisito per farlo funzionare: il codice deve essere abbastanza facile da leggere e capire.

Sfortunatamente, progettare linguaggi non solo estremamente espressivi ma anche estremamente leggibili è difficile. Lingue come Go danno la priorità alla leggibilità e ostacola il pensiero di livello superiore.

Infine, nella mia esperienza, linguaggi e strumenti migliori non portano a software con meno bug, ma piuttosto a progetti più grandi. Non c'è davvero alcun modo plausibile che pandocsarebbe stato scritto nel 1970.