Code Complete, 2nd edition

Autore: Steve McConnell - Editore: Microsoft Press - Pagine: 914 - Anno: 2004

• Ho trovato questa critica sulla prima edizione che riporto. Resta da verificare se ci sono state correzioni a riguardo sulla seconda edizione. La critica riguarda la metafora usata sulla realizzazione del software come una costruzione edile. La costruzione del software è molto diversa da quella di una costruzione edile, ci sono aspetti del software che non corrispondono a quelli del mondo fisico. Ad esempio non è possibile sostituire le fondamenta di un edificio con altre fondamenta più solide perché c'è il desiderio di aggiungere nuovi piani, nel software questo è possibile e accade; dopo aver costruito le colonne di un edificio spostarle è estremamente costoso, nel software sostituire il lavoro fatto in un giorno qualunque esso sia costa solo quel giorno; un giorno spostare gli archi e le colonne al piano terra non costa niente e solo 2 giorni dopo che la base è gettata spostarli costa $10.000, nel software rifare il lavoro appena fatto i 2 giorni precedenti costerà sempre 2 giorni -- LucaMinudel [2005-12-11] ;oltre al fatto che nel software a differenza del modo fisico replicare una cosa infinite volte non ha nessun costo e quindi una buona idea può essere replicata all'infinito portando a notevoli risparmi. Questa metafora usata in Code Complete 1Ed porta a valutazioni sbagliate sul modo di fare disegno del software -- LucaMinudel [2005-12-10]

• "A software metaphor is more like a searchlight than a road map. It doesn't tell you where to find the answer, it tells you how to look for it. A metaphor serves more as a heuristic than it does as an algorithm." La metafora della costruzione del software rimane, assieme ad altre, così come notazioni sul fatto che cambiare un muro portante si può fare, ma costa molto di più che imbiancare una parete. Secondo me la cosa non è così grave... -- LorenzoBarbieri [2005-12-10]
• Riporto un link totalmente contrario all'analogia: http://www.jamesshore.com/Blog/That-Damned-Construction-Analogy.html -- LorenzoBarbieri [2005-12-19]
• Interessante anche questo saggio riportato come riferimento nel link precedente: http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm -- RiccardoGolia [2005-12-20]

• Non sono d'accordo su questa frase "nel software sostituire il lavoro fatto in un giorno qualunque esso sia costa solo quel giorno". Credo che se il lavoro di un giorno è fatto male, costerà di più perchè dovrà essere revisionato o addirittura riscritto, costituendo un costo sempre maggiore con l'aumentare delle dimensioni... -- FabioCozzolino [2005-12-11]

• Non la trovo grave solo che è una visione superata (com'è il resto del libro? Ne ho sentito parlare bene. Questà metafora è usata anche nella seconda edizione?). La visione corrente di disegno del software di basa su aspetti che sono specifici del software e opposti ai vincoli che esistono invece nel mondo fisico delle costruzioni edili:
• Posticipa le scelte di disegno sino a quando possono essere fatte alla luce dell'esperienza e possono essere messe in uso immediatamente; cioè riduci al minimo il disegno up-front e fai disegno in modo continuo durante lo sviluppo (da non confondere con 'non fare disegno') beneficiando dei feedback che ottieni dal codice.
• Usa immaginazione, i principi di disegno e l'organizzazione per ridurre e possibilmente evitare scelte di disegno difficilmente reversibili cioè difficilmente modificabili (ossia fa si che il costo delle modifiche resti reddirizzio per i miglioramenti e le opportunità di business che le hanno richieste). L'immaginazione nel disegno del software è l'unico limite a questo obiettivo, non ci sono limiti teorici o fisici.
• Riduci la complessità ed evita la duplicazione (dati, strutture e logica) -- LucaMinudel [2005-12-11]

• Premetto che non ho letto il libro... Vorrei però esprimere un parere diverso da quello espresso da Luca circa la metafora utilizzata per descrivere la realizzazione del software. Innanzitutto, vorrei sottolineare che nel caso dell'edilizia il risultato finale è concreto e visibile, cosa che non si può dire di un programma o di un sistema informativo più o meno complesso. In ogni caso, proprio il fatto che il risultato finale di un progetto di costruzione sia concreto e visibile rappresenta il motivo per cui io personalmente trovo la metafora utile da un punto di vista didattico (io stesso l'ho usata e la uso talvolta, e non solo per il software). Spiegare concetti astratti non è sempre facile, associare esempi concreti permette di chiarire concetti complessi in modo abbastanza immediato. Non sono pienamente d'accordo quindi con l'affermazione di Luca: "la costruzione del software è molto diversa da quella di una costruzione edile, ci sono aspetti del software che non corrispondono a quelli del mondo fisico". Come per l'edilizia esistono diverse tipologie di edifici destinati a diversi scopi, così vale per il software. Tutti siamo d'accordo nel dire che è impossibile sostituire le fondamenta di un grattacielo senza doverlo buttare giù, ma per una casetta o una capanna questo è possibile, anzi... magari neanche ci sono le fondamenta! E se per il Framework .NET dovessimo buttare via il CLR e ripensarlo da zero? Si potrebbe fare secondo voi? E a che prezzo? Il paragone ha senso, a mio avviso. In taluni casi esistono parti di un software che ne possono caratterizzare a tal punto il funzionamento da poter essere considerate cruciali tanto quanto le fondamenta di un palazzo. Siamo tutti d'accordo che la sicurezza nelle applicazioni è importante come lo sono le porte e le finestre per una casa, ma esistono edifici che non hanno nè porte, nè finestre, come esistono applicazioni per le quali gli aspetti di sicurezza non sono affrontati (più o meno volutamente). Una piazza o un ponte sono opere di costruzione, ma mi pare che non servano le porte! E ancora... Per realizzare una casa occorre un progetto, lo stesso vale per il software (anche nel caso di un approccio agile). Per costruire una casa è necessario avere un metodo e un approccio, lo stesso vale (o dovrebbe valere) per il software. Sono tutti aspetti di somiglianza. Come detto, la vera differenza è il tipo di risultato finale. Cambiare l'architettura e il concept di un software a lavoro ultimato può essere un bagno di sangue. Questo avviene perchè inevitabilmente l'impatto sui costi dei cambiamenti ingegneristici (si chiamano così) è crescente man mano che si passa dalla fase di concept e progettazione a quella di sviluppo vero e proprio, anche quando si sviluppa con un approccio agile (vedi figura). Detto questo, vorrei concludere dicendo che ogni metafora va presa con le giuste precauzioni (è una metafora proprio per questo) e ne vanno capiti il senso e gli ambiti di validità. In determinati contesti, esistono casi in cui una metafora perde la sua validità, ma non per questo il suo uso diventa meno efficace se applicato con attenzione e cognizione di causa. -- RiccardoGolia [2005-12-11]

• Ciao Riccardo, dici <<Cambiare l'architettura e il concept di un software a lavoro ultimato può essere un bagno di sangue.>>, il disegno up-front senza disegno continuo porta a situazioni in cui l'architettura si definsce all'inizio e si valuta/scopre come migliorarla solo alla fine quando ormai è certamente troppo tardi, con la frase <<un giorno spostare gli archi e le colonne al piano terra non costa niente e solo 2 giorni dopo che la base è gettata spostarli costa $10.000, nel software rifare il lavoro appena fatto i 2 giorni precedenti costerà sempre 2 giorni>> intendo dire che se stabilisci un disegno per risolvere un problema specifico del tuo sistema e subito lo metti in atto e lavori 2 giorni, la mattina del terzo giorno capisci che la strada presa è sbagliata, il prezzo di tornare indietro è solo quello dei 2gg spesi, mentre nella metafora edile subito dopo che hai fatto la gettata del pavimento spostare le colonnine e gli archi diventa non reversibile perché troppo costoso (devi rimuovere la gettata e demolire le colonnine e gli archi per togòlierli e sostituirli). Dici << In taluni casi esistono parti di un software che ne possono caratterizzare a tal punto il funzionamento da poter essere considerate cruciali tanto quanto le fondamenta di un palazzo.>> ed è proprio questo che la moderna accezione del disegno spiega come evitare, questo è il punto focale e se vuoi dirompente ed affascinante: l'immaginazione nel disegno del software è l'unico limite a questo obiettivo, non ci sono limiti teorici o fisici che impediscono di rendere il disegno evolvibile in modo agile rendendo modificabile/evolvibile il più possibile ogni parte. Un esempio concreto, si può implementare l'autenticazione usando pagina base che deve essere ereditata da tutte le pagine e chiamando il metodo dentro la pagina ossia in modo invasivo e altamente accoppiato oppure si può applicare in modo disaccoppiato con i web config ereditabili e gli http molules in modo completamente disaccoppiato e sostituibile, ed ecco che una parte che era una fondamenta inamovibile è diventata una proprietà evolvibile. -- LucaMinudel [2005-12-12]

• Ok, Luca, ho capito cosa intendi... Ma, in ogni caso, per realizzare un software bisogna partire da una idea (concept) in base alla quale vengono definiti quanto meno gli aspetti funzionali, i casi d'uso. Pensare e progettare un software non significa necessariamente centrare l'architettura giusta al primo colpo, con una azione di pianificazione e progettazione iniziale mastodontica. Su questo sono d'accordo e non è in discussione. Anzi penso che la progettazione sia una attività che va di pari passo allo sviluppo, anche se credo che sia indubbio che nella fase iniziale debbano essere comunque prese una serie di decisioni più o meno confermate in seguito durante lo sviluppo e le attività di refactoring del codice. Quello che intendevo dire è che realizzare un software (e si fa con qualsiasi progetto, non solo nell'ingegneria edile) significa innanzitutto definire uno scope (che comunque può evolvere) e porre un "recinto" a quello che si vuole fare (il CHE COSA). La definizione dell'architettura (il COME) è un aspetto diverso e, se vogliamo, parallelo e può essere affrontato con approcci diversi. Il COME è influenzato dal CHE COSA: un buon disegno limita questa influenza, ma non la rimuove. In taluni casi non si può procedere, se non con forti rischi, senza una chiara definizione del CHE COSA. Certo, gli aspetti funzionali possono variare, ma uno stravolgimento del concept e quindi dello scope iniziale possono di fatto invalidare un progetto, indipendentemente dalle scelte architetturali e dall'approccio seguito. -- RiccardoGolia [2005-12-12]

• Ho trovato questo link: http://www.agilemanagement.net/Articles/Weblog/AlanCooperonWhySoftwareDe-2.html dove si dice che la metafora della costruzione del software è sbagliata, e all'interno c'è questa bellissima frase: "if you ask a software guy to design a means of transport from San Francisco to Hawaii, he won't come up with a boat or a plane, he will put a bridge in a While loop." Leggete comunque tutto il post. -- LorenzoBarbieri [2006-02-23]

Coder to Developer

Autore: Mike Gunderloy - Editore: Sybex - Pagine: 297 - Anno: 2004

Microsoft .NET Framework: regole di stile e best practice

Autori: Francesco Balena, Giuseppe Di Mauro - Editore: Mondadori Informatica - Pagine: 640 - Anno: 2005

• Un ottimo libro, pieno di regole e consigli "pratici" dati dall'esperienza. -- LorenzoBarbieri [2005-12-10]
• Un libro non male, ricco di spunti e ideale per chi non sa da dove inziare a stabilire i propri standard. Solo una nota riguardo alla voce 27.36 del libro, ossia "Previuos Application Instance" che riporta una "best practice" non troppo "best". Il modo corretto è invece quello specificato qui: http://blogs.devleap.com/marco/archive/2005/07/07/5319.aspx. -- DavideMauri [2006-01-27]

C++ Coding Standards. 101 Rules, Guidelines, and Best Practices

Autori: Herb Sutter, Andrei Alexandrescu - Editore: Addison-Wesley Professional - Pagine: 240 - Anno: 2004

Professional Software Development

Autore: Steve McConnell - Editore: Addison Wesley - Pagine: 243 - Anno: 2004

• Più che un libro sulle regole di programmazione è un libro sulla professione di chi sviluppa software. Si può essere d'accordo o meno con le tesi del libro, ma vale veramente la pena di leggerlo -- LorenzoBarbieri [2005-12-10]

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries

Autore: Krzysztof Cwalina, Brad Abrams - Editore: Addison-Wesley - Pagine: 348 - Anno: 2005