Prima o poi i programmatori ci cascano tutti. Ma per capire di cosa stiamo parlando, dobbiamo fare un salto nel passato.
Cargo Cult, o culto delle merci, una pratica in voga in alcune società tribali melanesiane in seguito all’incontro con popolazioni occidentali, secondo cui ii credenti hanno in comune la fede nell’avvento di navi o aerei da trasporto con carichi di beni destinati agli indigeni. In pratica i credenti ritengono che questa consegna sia disposta grazie all’intervento di un entità divina.
Il culto del cargo si è maggiormente sviluppato durante la seconda guerra mondiale, quando le tribù indigene del Sud Pacifico ebbero modo di osservare, spesso proprio di fronte alle loro abitazioni, la più grande guerra mai combattuta da nazioni tecnologicamente avanzate quali America e Giappone. Le grandi quantità di attrezzature, forniture e armamenti che venivano consegnate ai soldati attraverso navi in mare, lanciati in volo tramite paracadute o trasportati in elicottero in piste di atterraggio, hanno provocato drastici cambiamenti nello stile di vita degli isolani, molti dei quali non avevano mai visto prima degli estranei. Abiti, medicine, cibo, tende, armi e altri beni arrivarono in grandi quantità per i soldati e, spesso, venivano condivisi con gli isolani i quali erano le loro guide e i padroni di casa.
Ma la guerra cessò, le basi militari dell’Oceano Pacifico furono chiuse e di conseguenza cessò il rifornimento di merci. Tuttavia, per attrarre nuovamente le navi e invocare nuove consegne di merci, i credenti del culto del cargo istituirono rituali e pratiche religiose, come la riproduzione grossolana di piste di atterraggio, aeroplani e radio e l’imitazione del comportamento osservato presso il personale militare che aveva operato sul luogo. Durante la seconda metà del Novecento il culto del cargo è diminuito fino a scomparire quasi del tutto. Sull’isola di Tanna, nella Repubblica di Vanuatu, sopravvive ancora il culto di Jon Frum, uno dei più conosciuti, che nacque prima della guerra e divenne in seguito un culto del cargo.
Ma torniamo a noi. Cosa c’entra questa storia in tutto ciò?
Cargo Cult Programming, riprende in pratica i concetti del Cargo Cult melanesiano. Si tratta di un “anti-modello” metodologico in cui gli sviluppatori includono del codice nel loro programma, ma non conoscono né comprendono il ragionamento per cui quel codice deve essere incluso; sanno solo che includendo il codice, il programma funziona come previsto (o come sperato).
Un ottimo esempio è il copia-incolla di pezzi di sorgente. E’ anche vero che questo approccio potrebbe rivelarsi efficace: copiare e incollare un po’ di codice già pronto all’uso implementato da terze persone, quindi modificarlo e testarlo fino a quando funziona (o funziona in qualche modo…) velocizza sicuramente il processo di implementazione del programma. Un altro esempio potrebbe anche essere la mancanza di istruzione: il programmatore non ha contezza di come realmente funzionano gli strumenti che sta usando.
Perchè la CCP potrebbe essere un problema?
Non è solo un semplice copia e incolla di pezzi già pronti. Stai facendo quello che fai senza mettere in discussione o non ripensare continuamente ciò che già funziona per te (un po’ come quello che i giapponesi Zen chiamano beginner’s mind).
Come afferma Eric Lippert, i programmatori cargo cult “lottano” per apportare modifiche significative a un programma e finiscono per usare un approccio “prova e sbaglia” (Trial and error) poiché non comprendono il funzionamento interno del codice che stanno per cambiare. Questo non è tanto diverso da ciò che viene definita programmazione per concidenza: se non sai come o perché il tuo codice funziona, non capirai cosa è successo quando non funziona più.
Qualche esempio
Esempio in C#: tipo di valore non nullable
public Product Find(int id)
{
if (id != null) // this check is useless
{
Console.WriteLine("This line will always get reached.");
}
return new Product();
}
Try-Catch dapertutto!
Conosciuta anche come sindrome Pokémon (Gotta Catch ‘Em All! – Devo prenderli tutti!), si riferisce all’anti-pattern, anzi all’esigenza di dover aggiungere un blocco try-catch a ogni singola linea che potrebbe eventualmente generare un’eccezione.
Inutile tentate di rilevare un’eccezione del tipo System.Exception invece di un’eccezione più specifica, si rischia di confondersi tra errori previsti e imprevisti. Il consiglio generale è non cercare di catturare tutte le eccezioni a meno che non è necessario per il funzionamento vitale del programma o non si ha un valido motivo per catturarle. Questo articolo dovrebbe chiarirvi le idee in merito.
Cargo Cult in Javascript
Il Cargo Cult è curiosamente comune in JavaScript, probabilmente a causa della generale bassa barriera all’ingresso nel mondo dello sviluppo del front-end. Possiamo creare una pagina HTML con un po’ di JavaScript in pochi secondi. Di conseguenza, ci sono molte persone che diventano sufficientemente competenti per sentirsi a proprio agio nel creare e imporre regole a se stessi e agli altri. E i nuovi arrivati copiano queste regole. Le regole dogmatiche emergono e si diffondono, fino a quando non sono considerate la norma:
- Utilizzare sempre operatori di uguaglianza rigorosa
- Non usare mai eval
- Utilizzare sempre una singola dichiarazione var per ambito
- Usa sempre un IIFE perchè ti “protegge”
Una regola continua a diffondersi fino a quando un programmatore non utilizza solo una determinata tecnica a causa della sua popolarità, invece di considerare indipendentemente ogni caso d’uso specifico.
C’è un rimedio?
Direi che è giusto presumere che gli sviluppatori più inesperti siano più inclini a commettere errori a causa della programmazione Cargo Cult. Ma nessuno sviluppatore ne è veramente immune, indipendentemente dalle loro conoscenze o esperienze. Dopotutto siamo umani: stanchezza, scadenze, preconcetti cognitivi e (per essere sinceri) la pigrizia, può trasformare anche il miglior sviluppatore in un programmatore di culto del carico.
Sfortunatamente, non esiste un modo garantito al 100% per impedire che ciò accada. Eppure ci sono alcune misure che potremmo prendere per almeno ridurre le probabilità.
Revisione del codice / programmazione condivisa con altri
La prima misura è semplicemente ottenere un secondo paio di occhi sul codice. I vantaggi di avere una seconda persona che revisiona ogni riga di codice prima che vada in produzione non può essere sopravvalutato. E mentre la revisione del codice e la programmazione condivisa non sono equivalenti perfetti, entrambe queste pratiche offriranno qualche vantaggio in più.
Verificare sempre le proprie ipotesi
Scriviamo degli unit test (e anche altri tipi di test). Monitoriamo l’applicazione in produzione. Se qualcosa non funziona bene, facciamo un benchmark. Non diamo per scontato le cose.
Leggere il codice di altre persone
Leggere il codice di altre persone è un ottimo modo per imparare. È uno strumento perfetto per confrontare le proprie idee e assunzioni con quello che fanno gli altri sviluppatori, esponendoci a nuovi concetti che possono “costringerci” ad acquisire una comprensione più profonda dei problemi in questione. Nell’era di GitHub , non ci sono molte scuse per non farlo.
Impara dagli strumenti
Esistono numerosi strumenti che possono aiutare un team a migliorare la qualità del proprio codice . Ecco il punto, però: non dobbiamo semplicemente usare questi strumenti ma dovremmo anche imparare da loro. Cerchiamo di capire la logica che sta dietro di loro. Quali sono i principi e le migliori pratiche che hanno guidato i suoi autori nell’elaborare le regole.
