Oggi voglio inziare una serie di post con riflessioni venute alla luce affrontando una situazione che fin troppo spesso capita a chi lavora nel ramo dell’informatica : sviluppare a partire da un’applicazione scritta male, anche malissimo, da altri. Scritta male può voler dire tante cose: poco e mal commentata, costruita su logiche non ottimali e contorte, piena di errori non facilmente rintracciabili, mancante di funzionalità essenziali eppure non facilmente integrabili. Nei casi più ardui, si ha un prodotto che è stato costruito nel peggiore dei modi, come un corpaccio con tre gambe e quattro braccia. Capita anche quasi sempre che non si abbia il tempo di riscrivere l’applicazione, ma ci si debba accontentare di aggiustarla un poco alla volta. Capita che gli srtumenti su cui ci si deve basare siano diventati obsoleti ma che non si possa cambiarli. Esiste un modo ottimale di affrontare tutto questo? Il mio progetto di questo periodo è quello di scoprire una risposta sensata a questa domanda. Sarebbe molto bello se si aprisse una discussione.
Il primo aspetto che voglio considerare può sembrare più superficiale di quanto non sia: quello “estetico”. Con aspetto “estetico” voglio indicare tutto quello che riguarda lo stile e l’abbondanza dei commenti, i nomi scelti per le variabili, le classi e le funzioni, ed il modo di impostare i messaggi all’utente e l’uso di una struttura di log. Inanzitutto i commenti sono sacrosanti : lo ripetono a più non posso tutti i libri di informatica, ed è un messaggio che continua a non passare. Servono soprattutto proprio per chi il codice lo ha scritto e lo deve rivedere, magari a mesi di distanza, col rischio molto concreto di non riconoscere più il suo stesso lavoro. I commenti devono essere frequenti ma non ossessivi e non devono esprimere verità lapalissiane (“int p; // definisco un intero”). Il tempo speso a scrivere, razionalizzare e pulire i commenti non è sprecato. Fin qui tutto noto. Cosa capita nella realtà? Finora ho trovato :
- frammenti estesi e complessi di codice senza alcun commento;
- commenti inutili che in alcuni casi aumentano persino la confusione;
- grandi stralci di codice ridotti a commento in una fase di “transizione” e poi mai eliminati.
Cominciando dai frammenti privi di commenti, la cosa che mi sembra giusta è fare un’analisi approfondita, capire il flusso del codice ed inserire i commenti che lo chiarificano. Così com’è, anche se è un’accozzaglia di istruzioni indegna del nome di codice: magari si riscriverà, magari si correggerà: ad ogni modo si aggiungono delle note utili. Un piccolo trucco che spesso ho trovato utile è usare delle sigle personali per distinguere i miei commenti dai pochi già presenti e poterli ritrovare con agio. Spesso metto anche una data, in modo da ricostruire l’ordine delle operazioni. Altra cosa : i commenti dovrebbero, se possibile essere scritti nel modo più sobrio e “scientifico” possibile, anche in inglese in base al contesto di utilizzo.
Commenti inutili: credo che possano essere eliminati senza alcun rimorso. L’importante è essere sicuri che siano davvero inutili: se da un lato pulire è bene, dall’altro non bisogna neanche farsi prendere la mano dalla sindrome del “seek and destroy”. Altrimenti si rischia di fare cose di cui poi ci si pente. Senza dimenticare che con un buon sistema di controllo versione (SVN) è sempre possibile ripararsi dalle catastrofi piccole e grandi. Bisogna anche essere onesti e riguardare i propri commenti: ci si può accorgere, a posteriori, che alcuni potrebbero essere riscritti o eliminati. I commenti sono parte integrante del codice, che dovrebbe essere una cosa “vivente”, in evoluzione, in crescita, perfettibile sempre.
Infine, cosa fare quando grossi stralci ridotti a commento sporcano il codice, lo rendono poco leggibile ma lasciano anche il sospetto di poter rivelare qualcosa di utile sulle intenzioni originali del programmatore? Ci si ritrova a chiedersi se eliminando questi blocchi di codice “dormienti” non ci si stia negando la possibilità, un domani, di avere uno strumento valido per riscrivere correttamente il codice in questione. Non ho risposte sicure a riguardo. Una prima soluzione potrebbe stare nel fare un archivio dei file originali con tutti i commenti intatti e di tenerne un semplice registro. Un’altra soluzione potrebbe consistere nello spostare i blocchi in questione in calce ai file di competenza, lasciando un semplice richiamo nei punti originali e marcando il posto in cui si trovavano prima di essere spostati.
Nella prossima discussione, vorrei occuparmi della questione dei nomi delle variabili, delle classi e delle funzioni. A presto.
Oggi ho pensato alla biblioteca che vorrei e che non ho. Vorrei una biblioteca grande, fornitissima, aperta fino a tardi, tutti i giorni (magari meno la domenica). La vorrei come servizio essenziale, come luogo d’incontro per i cittadini, per gli eventi. Come luogo per passare una serata a leggere, per fare una ricerca, per organizzare una lettura di poesia, una conferenza. Per guardare un film, anche in gruppo, per ascoltare la musica. Vorrei poterci anche mangiare.
