|
Avendo veramente apprezzato Object Oriented Perl, OOP da qui in poi,
attendevo una nuova pubblicazione di Damian Conway con una trepidazione
appena leggermente inferiore a quella con cui alcuni di noi attenderebbero
la scoperta di manoscritti perduti di Douglas Adams sulla Vita, L'Universo
e Tutto Quanto. Il libro mi ha talmente spiazzato che ho dovuto scriverne
una recensione per cercare di scoprire che cosa ne penso veramente.
Questa recensione è la testimonianza di questo processo di autoanalisi.
Nutrito dalle aspettative suscitate da OOP, capace di chiarire realmente
l'implementazione della programmazione a oggetti in Perl, e quindi dando un
contributo importante alla comprensione di cosa il Perl sia e cosa possa fare,
scoprire che al capitolo due di Perl Best Practice, PBP da qui in poi, alla
voce bracketing, sono state spese due pagine per stabilire se sia meglio
mettere le parentesi alla K&R (Kernighan & Ritchie, non offenderò nessuno
cercando di ricordare chi siano) o alla BSD, mi ha procurato un leggero ma
persistente shock. Giusto per capirci,
la
questione sviscerata è se sia
meglio mettere la parentesi (parentesi tonda oppure quelle che in inglese si
dicono braces, parentesi di apertura/chiusura blocco) sulla prima riga
successiva all'istruzione che precede il blocco (BSD) oppure sulla medesima
riga (K&R). Non svelerò la ragione di questa prescrizione per non
ammazzare la suspence che indubbiamente non mancherà di attanagliare i
lettori più pensosi. Analogamente, le rigorose prescrizioni nel merito
della lunghezza delle linee di testo (78 caratteri) che seguono subito dopo ed
una accurata analisi di quanti spazi è bene indentare il testo per
agevolarne la leggibilità, lo, confesso, mi hanno fatto veramente temere
il peggio. Dov'erano finite le illuminazioni che hanno animato le pagine di
OOPS (si veda "blessing other things" in caso di dubbi)?
La risposta è che l'obiettivo di Conway non è quello di comunicarci
finezze capaci di appagare la nostra libido computandi oppure di farci sentire
molto intelligenti (anche perché sembra che Mark Jason Dominus, per sua
esplicita ammissione, sia uno dei rarissimi casi in cui la fluenza in Perl
abbia fatto colpo su qualche ragazza: si veda "A note about the cover" High
Order Perl), ma vuole invece fornire al lettore specifiche per la stesura di
codice perl che mettano in condizione di produrre software in modo più
professionale e con maggiore qualità. Si intende qui come qualità
quella che può apprezzare un manutentore del codice (che potrebbe essere
una vostra istanza di qualche giorno posteriore): leggibilità,
manutenibilità, riusabilità, secondo quanto recitano tutti i
mantra del software engineering. Sebbene la sovraspecificazione (si dice
così?) possa avere controindicazioni e provocare effetti collaterali
sotto forma di leggere dispnee se si è in ambiti aziendali già di
per se sovrastrutturati, tuttavia il testo di Conway persegue un obiettivo
coerente che vuole intervenire sulla polvere che potrebbe essersi depositata
sotto alcuni riposti ed acconci tappetini di qualche sviluppatore. Ovvero:
Conway non vuole arricchire la vostra intuizione o conoscenza del Perl (o non
più di tanto): vuole migliorare come scrivete codice Perl, il vostro
*processo* per dirla aziendalmente. Se è consentita un po' di ironia da
parte di un perlista convinto, suppongo che per ottenere questo risultato ci
volessero le maniere forti, ed ecco probabilmente il perché
dell'apertura del volume con le prescrizioni sulle parentesi.
Amplifichiamo. Una scorsa all'indice ci dice solo apparentemente quali sono i
temi: code layout; naming conventions; values and expressions; variables;
control structures; documentation; built-in functions; subroutines; I/O;
references; regular expressions; error handling; command-line processing;
objects; class hierarchies; modules; testing and debugging; miscellanea.
Code layout e specialmente naming conventions, con tutta probabilità, sono i
soli indizi del fatto che il testo non è un "normale" testo di Perl a
cui siamo abituati - anche se il secondo titolo potrebbe provocare un
involontario sussulto in chi, come riflesso condizionato à la Pavlov,
sia molestato da un qualche ricordo a proposito della Hungarian Notation. Il
vero tema diventa invece evidente da alcuni paragrafi; cito ad esempio:
ambiguous abbreviations; ambiguous names; unnecessary subscripting; list
processing side effects; ogni istanza del termine "documentation"; homonyms;
lazy flags. Eccetera. Il testo è strutturato catechisticamente: le
unità base di senso sono precetti (piuttosto lapidari, peraltro): fai
questo / non fare quello, a cui segue il commento che indaga e da ragione del
precetto, tecnica che ha antecedenti illustri nella letteratura religiosa di
tutti i popoli.
Il testo è chiaro, preciso e ha il merito di mettere il lettore di
fronte a un problema: prendere posizione di fronte alla necessità
indicata dall'autore, ovvero operare scelte consapevoli in funzione di una
gestione professionale del proprio modo di stendere codice. Per dirla
diversamente: questo libro non si rivolge a voi che scrivete Perl: si rivolge a
voi che vi guardate scrivere codice Perl. Altrimenti: questo non è un
testo sulla tecnologia del Perl, è un testo sulla pratica del Perl.
Se da un lato l'applicazione acritica e in toto dei comandamenti - oops - delle
regole indicate può in alcuni casi risultare francamente discutibile (mi
viene in mente un qualche recensore che, entusiasticamente, menziona il fatto
che il testo costituisce il "Department coding standards, period"),
d'altro canto i coding standard sono necessari anche se si scrive codice in
totale solitudine, appena che il codice debba essere consegnato a un cliente.
Stabilito quindi che i coding standards stanno al software engineering come i
litigi ai matrimoni (ricordate? troppi litigi avvelenano la convivenza;
l'assenza di litigi porta alla noia; ergo esiste un numero ottimale di litigi),
e postulato il fatto che voi vogliate migliorare il vostro modo di gestire la
stesura del codice, la domanda cui rimane da dare risposta è se questo
testo risponda a questo diverso tipo di aspettative. In parole povere, vale la
pena di arricchire la vostra biblioteca con questo libro?
La riposta dipende in modo essenziale A) da chi siete voi ma anche - sorpresa -
B) in quanti siete voi. Come sviluppatore individuale, caso A), ovvero come
singolo programmatore, il testo presuppone che il vostro viaggio nel mondo del
Perl abbia superato la fase eroica (quale sia stata la sua durata) e siate
entrati in quella maturità che prevede, auspicabilmente, una discreta
padronanza delle tecniche ma soprattutto una esperienza o una
sensibilità professionale che vi abbia portato a capire cosa c'è
realmente alla base di un solido mestiere come programmatore, il che non
è correlato necessariamente con la capacità di scrivere codice
particolarmente geniale (si veda l'aforisma: "Don' be clever" a pag. 453). Come
team (caso B)) Conway presuppone che siate per l'appunto un team e quindi che
sia vostro interesse concordare un insieme di regole che vi impediscano di
litigare a morte tra di voi e/o di chiudere l'azienda, generalmente in
quest'ordine. In entrambi i casi Conway vi fornisce un repertorio di precetti e
istruzioni che, recepito con intelligenza, senza sottrarsi al compito di una
propria valutazione e verifica, è senz'altro utile e spendibile,
nonché punteggiato qui e là da informazioni e suggerimenti assai
interessanti. Quanta parte di questo repertorio effettivamente entrerà
poi nel parco delle vostre tecniche e faccia al caso vostro, stante la
professionalità del testo e la indubbia qualità della scrittura e
della esposizione, non è facile dire perché ciò dipende
dal vostro grado di maturazione come software engineer, dal vostro grado di
disciplina, dal fatto che abbiate già idee estremamente chiare su come
dovete gestire il processo di software coding: se vi chiamate Steve Mc Connell,
Andrew Hunt o David Thomas questo testo potrebbe avere un impatto piuttosto
limitato sulla vostra vita. Tuttavia l'autore di questa modesta recensione
è a sua volta uno di coloro convinti che, forse, la fama del perl come
"executable line noise" è dovuta più ai perlisti che al Perl e che una
maggiore attenzione agli aspetti meno divertenti ma decisamente più
sostanziali della stesura del codice può far crescere numero e
qualità delle soluzioni Perl che fanno contenti gli utenti - e quindi,
in ultima analisi, la comunità dei perlisti. In questo senso PBP
fornisce una serie di strumenti e occasioni di riflessione da accogliersi
positivamente e come opportunità da non trascurare, anche se, come
detto, alcuni precetti sono alquanto opinabili.
Vorrei aggiungere che il testo del Conway ha una caratteristica che me lo rende
particolarmente simpatico: è un testo anti-ego. Ovvero, è un
libro che privilegia la formazione di un solido, onesto mestiere a scapito
della tentazioni di quel ramo della programmazione che fa parte della
Apocalittica, ovevro in cui la realizzazione di codice è lo strumento di
elezione per la rivelazione al resto del mondo della propria intelligenza
(altresì noto come Primadonna Programming). Per questa ragione,
nell'approccio al libro, invito a usare una tecnica inversa a quella
dell'assunzione di alcuni medicinali: usare bene prima di agitarsi,
perché pur mantenenendo, come detto, alcune riserve su certe paragrafi,
tuttavia questo libro merita attenzione e una buona sintonia (e potrebbe non
essere facile per tutti).
Concludo con una osservazione. Quella parte di software engineering attinente
il processo di coding è sempre stato focalizzato su team che sviluppano
con linguaggi considerati tradizionalmente di system programming: C, C++, Java,
ADA, eccetera, all'interno dei quali team il Perl poteva svolgere una funzione
ancillare, sia di prototipazione rapida che di proof of concept che di
tecnologia per la verifica della applicazione dei coding standard o
l'estrazione di metriche. L'ultimo sforzo di Conway invece sposta l'enfasi
indicando chiaramente la necessità e la possibilità di utilizzare
queste metodologie in applicazioni sviluppate con un linguaggio di scripting
per eccellenza. Da quel poco che so di Conway, questo più che un suo
auspicio mi sembra un dato di fatto presente in realtà fuori
dall'Italia. Sarebbe interessante capire più a fondo l'esperienza di chi
sviluppa Perl in Italia alla luce di questa affermazione.
|