[BOOKS] – Ingegneria del codice, Seconda Edizione

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.

Permanent link to this article: https://www.productivecsharp.com/2010/10/books-ingegneria-del-codice-seconda-edizione/


Warning: in_array() expects parameter 2 to be array, null given in /home/andreaa9/public_html/wp-content/themes/graphene/inc/plugins.php on line 92
  • Van Fanel says:

    "La traduzione non e’ particolarmente brillante" è un eufemismo… è la peggiore traduzione che abbia mai letto in vita mia! e per fortuna te l'hanno regalato: 80 euro per una simile traduzione è un vero furto.

  • Sono completamente d'accordo con te… era un modo carino per dirlo 🙂 Ormai e' sempre meglio leggere libri direttamente in inglese, cosa che faccio da moltissimi anni ormai. Non per niente, nel post, ho consigliato il testo in inglese. Il contenuto tuttavia e' eccellente.

  • Van Fanel says:

    Il contenuto tuttavia e' eccellente

    Su questo sono d'accordo… anche se per adesso ho appena passato la metà del libro: sono alla pagina con il disegnino del "bug".

    Non per niente, nel post, ho consigliato il testo in inglese

    Che tra l'altro su Amazon costa 30 dollari, cioè meno della metà!

    80 euro per leggere frasi che sono state evidentemente passate al traduttore automatico e poi corrette (male) a mano. Ne ho letti di libri di informatica tradotti male, ma questo li batte tutti. Alla Mondadori Informatica dovrebbero vergognarsi.

  • Van Fanel says:

    Per questi libri mal tradotti si dovrebbe coniare una nuova Legge di Murphy: "se una parola si può tradurre in due modi e il secondo è clamorosamente sbagliato e produce una frase senza senso, verrà sicuramente scelto quello".

    Ad esempio, a pagina 509 (capitolo 22.3): "states" può essere il plurale di "state" (stato) o la terza persona singolare del verbo "to state" (affermare). Dal contesto è evidente che in quella pagina la traduzione corretta è "stati", ma ad un certo punto viene tradotto… "dice", rendendo completamente senza senso una frase!

    Nuove frontiere della matemagica: a pagina 505 (sempre capitolo 22.3), scopriamo che 2620 * 2620 * 1010 fa… 1066 ! Ops, forse ci andavano gli esponenti…

    Altre "perle" non riesco proprio a capirle. Pagina 454, capitolo 19.5: "Dal quando la programmazione strutturata è giunta e andata, il termine 'strutturato' è stato applicato a ogni attività dello sviluppo del software"
    Ma che accidenti vuol dire?!?

  • >