La necessità di specifiche di progettazione del software è diminuita in modo significativo con l'evoluzione di linguaggi di programmazione più espressivi?

Mi domando la premessa che le lingue siano sempre più espressive. Con il codice ASP.NET di oggi in c #, scrivo all'incirca allo stesso livello di quando scrivevo 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:

1. 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 in codice piuttosto che nei documenti di Word.

2. Modifiche nella metodologia di implementazione. In passato era molto costoso commettere un errore perché sarebbe necessario spedire una copia aggiornata del software. Quindi dovevi stare attento. Con le applicazioni web-driven, puoi distribuire le correzioni per l'uso immediato e puoi permetterti di reagire ai problemi piuttosto che anticiparli, ristrutturando il codice man mano che lo fai.

3. Adozione di modelli di progettazione. Quando tutti conoscono gli schemi, è difficile progettare qualsiasi cosa; puoi semplicemente dire "aggiungi un factory di repository" e il tuo team dovrebbe farlo senza aver bisogno di vedere UML.

4. Contratti di dati SOA. Praticamente tutto è SOA in questi giorni. Tutto ciò di cui hai bisogno è un WSDL. I giorni di definizione e documentazione dei formati di trasferimento dei dati sono andati. L'attuale tendenza verso più RESTful e micro-servizi continua questa tendenza.

5. I software sono più piccoli. In parte come risultato delle architetture SOA, i team stanno scrivendo programmi più piccoli che sono legati insieme. Ogni singolo componente è meno complesso e richiede una progettazione meno anticipata; inoltre, è più facile cambiare parte dell'architettura senza interrompere la soluzione generale a causa delle interruzioni di fuoco forzate dalle definizioni dell'interfaccia tra i componenti.

6. Molto, molto più uso di librerie consolidate. .NET CLR offre un sacco di funzionalità disponibili, quindi non è necessario progettare, ad esempio, uno schema per i dati della sessione di memorizzazione nella cache. Le librerie di terze parti come jQuery UI o Bootstrap stabiliscono degli standard per scrivere codice per funzionare in un certo modo. Non è necessario documentarli; i team dovrebbero essere in grado di usarli.

7. maturità del settore. Gli SWE hanno appreso che non esiste un progetto "Battlestar Galactica" in cui passi anni e anni a cercare di raggiungere un obiettivo specifico; nel momento in cui quegli anni sono passati, l'obiettivo sarà cambiato. Oggi sappiamo che il time to market è molto più importante che ottenere tutto esattamente nel modo in cui lo vogliamo nel design.

8. Ingegneri meglio formati e più preparati. In questi giorni puoi assumere ingegneri che comprendono le migliori pratiche (si spera) e le implementeranno senza un documento di progettazione che indichi cosa fare.

9. Strumenti di produttività come TFS consentono di scrivere una semplice attività che fa riferimento a un caso d'uso e fornisce un paio di punti elenco per eventuali ambigue decisioni tecniche. Non hai bisogno di molto altro. Gli sviluppatori sono in grado di rivedere, stimare, ottenere revisioni del codice su, check-in, ecc. Attraverso lo strumento. Questo è molto più efficiente di lavorare con documenti esterni poiché lega tutto insieme.

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

Direi per No .

Per una semplice ragione che

For many IT people, including myself a few years ago, the ideal software development process would involve the creation of detailed design documents with lots of UML diagrams before a line of code gets written.

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

In the ideal case there should be no description of software design except the code itself.

È stato discusso per anni fa. Ad esempio questo leggendario articolo del 1992: Cos'è il Software Design .

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

Direi che questo passaggio "apparente" dal design-up-front con molti diagrammi e documenti di casi d'uso a un approccio più evolutivo e iterativo è semplicemente la sostituzione dei manager della "vecchia scuola" con quelli nuovi, che sono cresciuti in un ambiente molto più dinamico e per chi è molto più facile accettare e lavorare in un ambiente più "agile".

Sono praticamente d'accordo con questo, ma penso che sia iniziato molto prima di quanto tu insinui. Penso anche che ci sia un altro grande fattore oltre all'espressività. Quando mio padre ha iniziato a programmare, ha dovuto creare schede perforate e programmare il tempo sul computer. Potresti avere una possibilità al giorno di eseguire il tuo programma. Non c'era molto tempo per sprecare il codice edilizio, lasciarlo fallire e quindi ripararlo. Hai forse 2 o 3 colpi e se non funzionava, eri nei guai.

Il rischio di ciò significava che era fondamentale dedicare un sacco di tempo in più per pianificare il tuo programma. Le persone scriveranno il loro codice a matita e poi lo trasferiranno sulle schede perforate. Con il progredire della tecnologia, è possibile codificare direttamente nel terminale, ma si stavano ancora utilizzando risorse condivise e la CPU era costosa. Una metodologia test-first sarebbe del tutto insostenibile in quel mondo. Se non hai pianificato in anticipo, i tuoi pari saranno alla tua scrivania con forconi.

Le risorse informatiche sono diventate meno costose e migliori a un ritmo incredibile. Molti dei vincoli sotto i quali tutte queste pratiche sono state sviluppate sono completamente cancellate. Come sottolinea Euforic, l'allontanamento da questo è iniziato negli anni '90. La continuazione di gran parte del grande design anteriore è stata pura inerzia.

Quindi, sì, l'espressività migliorata dei linguaggi di programmazione ha avuto un impatto su questo dal semplice fatto che è più facile usare il codice espressivo come se fosse la propria documentazione. Il costo di produrre un documento che ti dice che cosa dice il codice è molto alto e il suo valore (è inevitabilmente sbagliato a un certo livello). Allo stesso tempo, il costo di buttare cazzate al muro e vedere quali bastoncini è sostanzialmente trascurabile. p>     

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

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

Non è necessario disporre di documenti che descrivono il comportamento esatto del sistema di sistema in tutti dettagli, poiché in effetti il codice sorgente serve proprio a questo scopo.

Lo sviluppo del software potrebbe essere considerato il processo di trasformazione di specifiche umane leggibili ad alto livello in specifiche univoche di basso livello che sono eseguibili da una macchina. Ma hai bisogno di un input per questo processo.

In the ideal case there should be no description of software design except the code itself.

Questo è più lontano di quello che intendi. Anche cose come i tipi dipendenti (che, a quanto ho capito, sono abbastanza promettenti teoricamente) sono diversi anni.

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

Unit tests

Se i test di proprietà non hanno colpito il mainstream, non penso che ciò sarà pratico per molto tempo.

Inoltre, scrivere buoni test (che non dovranno essere modificati con ogni refactator ma riscuoterà comunque abbastanza errori) è piuttosto difficile.

To make sure that the code is consistent with your documents you have to check again and again. If there are frequent changes, it is hard to keep code and documents in sync.

Probabilmente è più facile usare uno strumento di test della documentazione al momento.

There is one precondition to make this work: The code has to be easy enough to read and understand.

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

Infine, secondo la mia esperienza, linguaggi e strumenti migliori non portano a software con meno bug, ma a progetti piuttosto grandi. Non c'è davvero alcun modo plausibile in cui pandoc sarebbe stato scritto nel 1970.