Tutti quelli che mi conoscono sanno quanto mi piace leggere e imparare cose nuove. In particolare adoro leggere libri tecnici per aumentare le mie competenze e imparare dall’esperienza di tanti altri che mi hanno preceduto. Per questo motivo ho deciso che ogni volta che terminero’ la lettura di un libro scrivero’ un post in cui racchiudero’ l’essenza del libro e le mie considerazioni. Lo scopo e’ riassumere il contenuto, evidenziando i punti principali e piu’ importanti. Spero che possa anche accendersi un dibattito e un confronto costruttivo sui contenuti con le persone che hanno letto il libro o quelle che desiderano acquistarlo.
Ho deciso di inaugurare questa sezione del mio blog con un testo classico che ho recentemente finito di leggere:
“
Ingegneria del Codice, Seconda Edizione” di
Steve McConnell
Questo libro mi e’ stato regalato da alcuni amici dell’universita’ di Pisa per la mia laurea triennale nel 2006. Il libro e’ in italiano. La traduzione non e’ particolarmente brillante, quindi per coloro che avessero intenzione di acquistarlo consiglio il testo in lingua inglese:
“Code Complete, Second Edition”
Il libro e’ un mattone di 900 pagine che affronta a 360 gradi tutto cio’ che riguarda la costruzione del software. Esso presenta una serie di pratiche di programmazione che servono a mantenere sotto controllo, a manutenere e a modificare grossi e complessi progetti. Il libro e’ una raccolta di innumerevoli fonti integrate con anni di esperienza professionale. Dal mio punto di vista, il suo valore e’ altissimo e molto probabilmente dovro’ leggerlo una seconda volta, magari in inglese.
Uno degli aspetti interessanti del libro e’ il numero di ricerche statistice che vengono riportate per supportare le tesi sostenute.
Ecco alcune frasi significative estratte dal testo:
- Il prodotto della costruzione, il codice sorgente, e’ spesso la sola descrizione accurata del software. Di conseguenza, e’ imperativo che il codice sorgente sia della piu’ alta qualita’ possibile.
- I rischi di progetto piu’ comuni nello sviluppo del software sono i prerequisiti scarsi e una scarsa pianificazione di progetto
- Parte del lavoro di dipendente tecnico consiste nell’educare il personale non tecnico che vi circonda sul processo di sviluppo
- In generale, il principio e’ trovare un errore nel momento il piu’ vicino possibile a quando e’ stato commesso
- Il primo prerequisito che si deve soddisfare prima di iniziare la costruzione e’ una formulazione chiara del problema che si vuole risolvere: la mission del prodotto
- I prerequisiti stabili rappresentano il sacro Graal dello sviluppo del software
- I programmatori che non dimenticano di considerare l’impatto business delle loro decisioni valgono tanto ora quanto pesano
- Una delle maggiori sfide che si presenta a un architetto software e’ rendere l’architettura abbastanza flessibile da favorire le probabili modifiche
- Prima che la costruzione inizi, specificate le convenzioni di programmazione che utilizzerete.
- I tool di programmazione utilizzati non devono determinare come si interpreta la programmazione
- Il design e’ l’attivita’ che collega i prerequisiti alla codifica e al debugging.
- L’imperativo tecnico principale del software e’ gestire la complessita’
- Abituatevi a chiedervi “Cosa devo nascondere?”. Resterete sorpresi dal come molti difficili problemi di design si dissolveranno davanti ai vostri occhi
- Talvolta non si puo’ realmente sapere se un design funzionera’ finche’ non si comprendono meglio alcuni dettagli di implementazione.
- Il design e’ euristico. Una adesione dogmatica a qualsiasi singola metodologia danneggia la creativita’ e danneggia i programmi
- I programmatori nel corso dell’esistenza di un sistema spendono molto piu’ tempo a leggere il codice che a scriverlo
- Le revisioni rappresentano un meccanismo importante per fornire ai programmatori un feedback sul loro codice
- La scrittura dei test case prima del codice richiede la stessa quantita’ di tempo e impegno della scrittura dei test case dopo il codice, ma accorcia i cicli difetto-rilevazione-debug-correzione
- Neanche l’esperienza aiuta molto con l’ottimizzazione. L’esperienza di una persona puo’ essere stata acquisita su una macchina, un linguaggio o un compilatore ormai datato: se cambia uno di questi aspetti, tutte le certezze sono errate. Non si puo’ mai essere certi sull’effetto di una ottimizzazione finche’ non si misura l’effetto.
- Piu’ cervelli bisogna coordinare, piu’ documentazione formale e’ necessaria per coordinarli
- Utilizzare il sistema di benefit della propria azienda per incentivare le buone pratiche di codifica
- Gestire un progetto software e’ una delle imprese piu’ eccezionali del ventunesimo secolo, e stimare le dimensioni di un progetto e l’impegno richiesto per terminarlo e’ uno degli aspetti piu’ impegnativi della gestione di un progetto software
- I buoni programmatori tendono a raggrupparsi
- I manager dei progetti di programmazione non sono sempre consapevoli che certi aspetti della programmazione sono questioni di religione
- Nello sviluppo del software, i manager non tecnici sono comuni, come lo sono i manager che hanno esperienza tecnica ma che e’ obsoleta di 10 anni. I manager tecnicamente competenti, e tecnicamente aggiornati sono rari. Se si lavora con uno di essi, fate di tutto per mantenere il vostro lavoro. E’ un piacere insolito.
- La soddisfazione visuale e intellettuale del codice ben formattato e’ un piacere che pochi non programmatori possono apprezzare
- Il Teorema Fondamentale della Formattazione dice che una buona disposizione visuale mostra la struttura logica di un programma. Se una tecnica mostra meglio la struttura e un’altra conferisce un aspetto migliore, utilizzare quella che mostra meglio la struttura
- Molti aspetti del layout sono aspetti religiosi. Cercate di separare le preferenze di obiettivo da quelle soggettive.
- I commenti inadeguati sono peggio di nessun commento
- Commentare il codice complicato e’ esattamente l’approccio errato da seguire. Non documentare il codice pessimo: riscriverlo.
Una cosa interessante che ho scoperto da questo libro e’ che il mio stile di codifica pur essendo esteticamente valido viola quello che l’autore chiama il Teorema Fondamentale della Formattazione. In pratica io preferisco mettere la prima parentesi di un blocco nella riga successiva. Lo trovo estremamente leggibile anche se talvolta porta ad un aumento del numero di linee di codice.
Come dice Steve:
I buoni programmatori devono essere di larghe vedute sulle proprie pratiche di layout e accettare le pratiche che si sono dimostrate migliori di quelle a cui sono abituati, anche se adattarsi a un nuovo metodo comporta un disagio iniziale.
I motivi per cui questo approccio e’ sconsigliato sono:
- Begin e End (le parentesi) non fanno parte del costrutto di controllo, ma non fanno neanche parte della istruzione seguente
Onestamente tuttavia non lo trovo un motivo sufficiente per farmi cambiare il mio stile di formattazione dei blocchi. Sarei curioso di sapere il vostro. Qual e’ ?
Altre frasi:
- Se siente un ingegnere del software, il materiale di base di costruzione e’ intelletto umano e il vostro strumento primario siete voi. Piuttosto che progettare una struttura fino all’ultimo dettaglio e poi passare i disegni a qualcun altro per la costruzione, sapete che dopo aver progettato un blocco di software fino all’ultimo dettaglio, e’ fatta. L’intero lavoro della programmazione e’ realizzare castelli in aria: e’ una delle attivita’ piu’ puramente mentali che si possa fare.
- Se volete essere validi, e’ vostra la responsabilita’ di rendervi tali. E’ una questione di carattere personale.
- Nello sviluppo di un ottimo programmatore la curiosita’ sugli argomenti tecnici deve essere una priorita’.
- Un modo particolarmente valido per apprendere la programmazione e’ studiare il lavoro di ottimi programmatori.
- Alcuni programmatori creativi vedono la disciplina degli standard e le convenzioni come qualcosa di asfissiante per la creativita’. E’ vero il contrario.
- Dijkstra ha costantemente sottolineato il messaggio che il compito essenziale della programmazione e’ padroneggiare l’enorme complessita’ della scienza dei computer.
- Per sperimentare efficacemente, si deve essere disposti a modificare le proprie opinioni in base ai risultati dell’esperimento
Il libro e’ una vera miniera di consigli e linee guida. Tuttavia e’ solamente un punto di partenza in quanto vengono elencate una raccolta sterminata di ulteriori libri/articoli/fonti su cui approfondire ed espandere gli argomenti trattati. Un intero capito e’ dedicato a questo scopo.
