Pigrizia, professionalità, programmazione…

Qualche giorno fa stavo mi sono trovato nel mezzo di una bella discussione circa il valore delle “coding convention” in un’azienda e quindi per estensione di stile nel modo di scrivere codice.

Si tratta di un argomento interessante e ricco di spunti (su cui ho già scritto in passato, per esempio qui e qui) e, a mio modo di vedere, spesso ignorato o trascurato.

Sfortunatamente parlare di stile, anche se applicato alla programmazione, riporta intuitivamente alla moda, all’essere trendy, eccetera. Qualcosa di potenzialmente percepibile come frivolo e di secondaria importanza.

O almeno è così se ci si accontenta di volerlo credere.

Professionalità è stile e molto altro!

Credo che la prima cosa che salta agli occhi leggendo il codice di una persona sia l’ordine, la pulizia e l’eleganza, quindi un fattore estetico.

Non che sia un punto secondario – la leggibilità e la chiarezza sono fondamentali, specialmente per chi deve leggere e capire il codice di qualcun altro – ma ne esiste un altro altrettanto importante, logico-funzionale, che include anche aspetti architetturali, ingegneristici ed è legato a come fare le cose.

Quest’ultimo punto è estremamente vasto ed abbraccia sostanzialmente l’intero modus operandi di una persona: quali schemi logici applica nel decidere, che tipo di approccio ha verso i problemi ha e come li aggredisce, quali sono i suoi bias iniziali, quali metodologie e strategie applica normalmente, quali sono le sue priorità e i suoi obiettivi in un progetto, come costruisce le soluzioni, eccetera eccetera.

Tanto il primo quanto il secondo punto sono qualcosa di migliorabile e qui sta il fulcro di questo post.

Apparentemente parlando di queste tematiche in pubblico non si ottiene un grande successo perchè migliorare è un processo faticoso, ha dei costi in termini di tempo e di risorse non indifferenti e, last but not least, richiede un preciso sforzo di volontà che non tutti sono disposti a compiere senza la prova provata di poterci guadagnare qualcosa, magari sul breve periodo.

Anche solo discuterne, interessarsi cioè all’argomento, a mio modo di vedere segna uno spartiacque fra un professionista ed un lavoratore, magari estremamente valido ma tutto sommato “normale“: non che il secondo debba per forza essere sinonimo di mediocre, ci mancherebbe, ma un professionista per definizione incarna un certo grado di specializzazione e di propensione al miglioramento continuo, quindi ad essere almeno informato sulle cose, sul cosiddetto stato dell’arte nel suo ambito di pertinenza. Se poi riesce anche ad applicarle, tanto meglio.

O così almeno dovrebbe essere.

Pericolosa pigrizia

All’Università uno dei miei professori-guru, Fiorentini, era solito ripetere qualcosa come:

“La pigrizia è il peggior pericolo per un programmatore ed il programmatore pigro finisce male.”

Tale pericolo è concreto perchè spesso deriva dalla comodità: più ci si trova a proprio agio in qualcosa – e ci si accontenta, beandosi di ciò -tanto più è difficile smuoversi, imparare cose nuove e, soprattutto, accettare eventuali cambiamenti.

Nello specifico, conoscere ed applicare una qualunque coding convention, significa innanzitutto sapere cos’è, capirne l’utilità e, magari, applicarne una che sia minimamente decente, non importa quale.

Lo stesso discorso può essere esteso a qualunque aspetto non basilare e non banale delle programmazione che tocca ambiti come, ad esempio, l’ingegneria del software.

Lasciatemi dire che resto mesto e mortificato quando mi sento dire, ad esempio, che l’ingegneria del software è qualcosa per “programmatori-fighetti“, per “chi ha tempo da dedicarci” o, peggio, che “non serve (conoscerla per programmare)“.

C’è perfino chi sostiene che sia semplicemente “roba da universitari“, quando invece esimi guru la pensano in modo diverso, lamentandone addirittura la carenza. Ad esempio, citando da Wikipedia:

“Steve McConnell opines that because most universities teach computer science rather than software engineering, there is a shortage of true software engineers.”

I risultati sono quelli che sono. Nulla di cui stupirsi se per certe persone il code reuse coincide nella pratica con un semplice copy & paste di codice da un programma all’altro. Tale prassi è invece nota come copy & paste programming e, ovviamente, non è indicata con toni trionfalistici.

Di rimando questo genere di tematica mi pare abbondantemente trascurata al punto che quando sento qualcuno parlarne con spirito critico e non solo per dar aria alla bocca, automaticamente il mio “essere-programmatore-dentro” si volge a lui in modo pregiudizialmente positivo. Cioè parto prevenuto in modo positivo nei suoi confronti perchè non conosco nessuno che “blateri” abitualmente di queste cose senza essere anche un signor programmatore.

Questo non significa che non ci siano anche molti bravi programmatori totalmente ignari di queste tematiche e, all’opposto, pessimi programmatori che parlano costantemente di queste tematiche solamente per farsi belli. Tuttavia la differenza la fa la qualità del loro output, ossia il loro codice.

Sviluppatore != Programmatore

In virtù di quanto appena detto credo che sia necessario introdurre in qualche modo una differenziazione professionale, anche solo fittizia, fra chi fa il suo lavoro senza lode nè infamia e chi si impegna a migliorare, rifuggendo le insidie della pigrizia.

In mancanza di meglio, giocherò sulle sfumature: proverò a differenziare i termini sviluppatore e programmatore, anche se nella pratica sono spesso usati come sinonimi.

Nel primo vedo qualcuno che pianifica, applica le sue conoscenze e le estende, informandosi, perchè vuole migliorare: una connotazione più sulla persona, più sulla sua professionalità che solamente su quello che realizza. Nel secondo vedo di più il concetto di realizzatore materiale, colui che scrive concretamente i programmi.

Forse è una mia fissazione superflua, ma applicandola, forse scoprirei di conoscere molti individui che incarnano più il programmatore che non lo sviluppatore. Non è una critica alle capacità di nessuno, ma credo che sia giunto il momento di fare un po’ di chiarezza. Dopotutto dire “questo programmatore è più bravo di quest’altro” è un’affermazione troppo generica, troppo poco significativa sulla sua professionalità.

Che ne pensate?