Cosa possono mai avere in comune la programmazione e l’arte? Non posso fare a meno di pensare alla questione intramontabile del “framework sì VS framework no”. C’è chi si rifiuta di lavorare con i framework perché vuole sentirsi libero, senza paletti di alcun tipo, come se ognuno di noi avesse uno stile e fosse tenuto ad esprimerlo. Sarò sincero: ho sempre pensato che questa sia l’opinione di chi non è riuscito a comprendere i vantaggi di un framework. Sono proprio i suoi vincoli, il costringerti a scrivere il codice in una certa maniera, a seguire dei pattern ciò che dovremmo apprezzare.
Qualsiasi buon progetto, che sia di piccole o di grandi dimensioni, deve porre delle regole che deve guidare tutti i membri del team. Lasciare che ognuno faccia quello che vuole sarebbe un errore da molti punti di vista e creerebbe incidenti in cascata. Se Goffredo affermasse di avere uno stile di programmazione tutto suo, allora potremmo aspettarci le peggiori porcate. Non me ne voglia Goffredo, ma dubito che il suo genio possa mai superare decine e decine d’anni di informatica moderna, fatta di formulazioni di principi, congetture, costrutti, astrazioni, paradigmi e pattern, evoluti nel tempo grazie allo studio di centinaia di matematici e informatici e all’esperienza consolidata di milioni di aziende nel mondo. No Goffrè, il tuo stile potrebbe essere solo mancanza di disciplina.
La disciplina di cui parlo è ciò che evita che il codice che scriviamo sia del tutto privo di criterio. Seguire un pattern non basta. Se tutti nel team usano un classico MVC e poi arriva Goffredo che introduce l’Event Sourcing, qualche problema potrebbe esserci. Perché arriverebbe Eusebio, che non sa nemmeno cosa sia l’Event Sourcing, e mettere le mani su quel codice, per lui, sarebbe complicato. Passerebbe un sacco di tempo nello studio del pattern prima di poter scrivere del codice e di conseguenza l’intero team verrebbe rallentato. Pensate a cosa succederebbe se tutti facessero come Goffredo. Vorrebbe dire lavorare con pattern per cui il team non ha maturato una buona esperienza, il che porterebbe inevitabilmente ad implementazioni errate o addirittura a bug, perché alle spalle dei programmatori c’è il project manager col frustino che chiede ritmi costanti e prestanti. In ogni caso ne seguirebbero problemi di manutenibilità, la produttività subirebbe duri colpi e tutto si ripercuoterebbe sul business.
Tutto sto pippone è per sottolineare l’importanza della disciplina. C’è bisogno di coordinazione e armonia. Un business è come un treno, che deve essere sempre puntuale, dove i vagoni sono le persone che ci lavorano e che non possono andare da nessuna parte se non trovano i binari – le regole – su cui viaggiare.
E dunque, se mi chiedessero se un programmatore sia o meno un artista, a voler essere breve risponderei con un secco no, perché Goffredo merda. Tuttavia, non è che chiunque dipinga quadri sia un artista in senso stretto. Anche l’arte può essere discussa con obiettività, perché c’è una differenza tra i girasoli di Van Gogh e l’obbrobrio che potrei dipingere io. Questa differenza è che un bravo pittore sa come usare ogni pennello, sa giocare con i colori e con i contrasti, sa posizionare le luci, conosce lo stile, sa adottare la tecnica. Se poniamo la questione in questo modo, forse il programmatore può essere un artista, perché prima di mettere le mani sul codice deve conoscere il linguaggio, i tool, i pattern, il progetto stesso.
Ma dove si esprime il suo estro? Per rispondere farò proprio come i grandi artisti: non copio, ma rubo! Robert C. Martin, nel suo best-seller Clean Code, intitola un paragrafo “The Art of Clean Code?” e afferma che programmare è come dipingere. Potremmo essere in grado di giudicare la fattezza artistica di un quadro, ma ciò non farebbe di noi degli artisti. Allo stesso modo, potremmo saper riconoscere del codice pulito, ma ciò non vorrebbe dire che sappiamo come scriverlo.
Infatti scrivere codice pulito è molto difficile. È determinante che il codice sia leggibile sin da subito, senza raccontarci la bugia del “va be, ma poi lo aggiusto”. Sia per la legge di LeBlanc “later equals never” (anche questa perla è in Clean Code), sia perché non scrivere codice leggibile comporta il fatto che, chi verrà dopo di noi (o anche noi stessi dopo qualche settimana) troverà difficile metterci mano, passerà del tempo a capire cosa fa quel codice, sarà meno efficiente. A lungo andare il codice diventa una matassa immantenibile, la produttività generale cala, lo stress aumenta e il business intero, ancora una volta, ne risente.
Scrivere codice pulito è un genere di cose che richiede uno sforzo intellettuale e creativo. Perciò, se vogliamo sentirci un po’ artisti, allora sfoghiamo la nostra immaginazione per scrivere codice pulito ed elegante: ben organizzato, semplice da leggere, immediato da comprendere e facciamo in modo che chi venga dopo di noi, anziché tirar giù calendari, trovi la propria quiete, come se si trovasse davanti alla notte stellata di Van Gogh.
