Lo scorso 4 novembre, durante la ScotlandPHP Conference 2017, ho avuto il piacere di assistere ad un inspirato intervento di Adam Culp sul tema dello sviluppo di codice pulito. Ho trovato tale intervento particolarmente interessante perché, se pur ribadendo concetti che tutti gli addetti ai lavori conoscono (o dovrebbero conoscere), Adam ha voluto porre l’accento sull’aspetto professionale della questione e sulle responsabilità dei soggetti coinvolti.
L’idea che molti hanno dello sviluppo software (talvolta anche in ambienti professionali) è che il lavoro consista semplicemente nella scrittura, nel minor tempo possibile, di codice privo di errori di sintassi e che restituisca l’output desiderato. Ma non è affatto così.
Lo sviluppo di software, come qualsiasi altra attività lavorativa,può produrre risultati di diversa qualità. Il codice che ne viene fuori può semplicemente funzionare (a volte nemmeno questo) o può essere ben strutturato, consistente, chiaro, essenziale, riusabile, e rispettare gli standard di codifica del linguaggio nel quale è stato sviluppato…
Del codice scritto in modo pulito richiederà più tempo per la prima stesura ma risulterà molto più semplice da manutenere, estendere o modificare quando se ne verificherà la necessità.
Chiunque di noi programmatori con un minimo di esperienza si è trovato nella vita a dover fronteggiare del codice cattivo, confusionario, con caratteristiche non ben chiare e definite. Sappiamo benissimo che tale sfortuna riduce drasticamente la nostra produttività: modifiche che dovrebbero richiedere qualche ora, infatti, si trasformano in stressanti maratone di tentativi falliti e rinvenimenti di scheletri negli armadi che possono durare giorni.
Un codice di scarsa qualità, inoltre, può rappresentare un serio problema per la longevità di un software. Correggere del codice cattivo e/o scriverne di pulito in un progetto di bassa qualità, infatti, è un qualcosa di davvero molto complesso: occorre tempo, una documentazione chiara e la conoscenza perfetta di tutte le specifiche. A volte può essere più conveniente avviare lo sviluppo di un nuovo software piuttosto che cercare di recuperare quello vecchio.
Prendete un qualsiasi programmatore e ponetegli la domanda: “E’ meglio sviluppare in modo pulito o veloce?”. Egli vi risponderà, ovviamente: “In modo pulito!”.
E allora perché esiste codice cattivo? Perché noi sviluppiamo codice cattivo? (E sì, perché tutti lo abbiamo fatto… e talvolta lo facciamo ancora…).
E’ possibile che non siamo capaci (richiede comunque una certa abilità), o che non ne abbiamo voglia in un particolare momento… ma il più delle volte, perché vogliamo accontentare qualcuno.
Difficilmente sviluppiamo codice per noi stessi: di solito c’è un capo o un cliente che, giustamente, spingono perché il lavoro sia completato al più presto e/o con in minor dispendio possibile di risorse. E’ normale. Dunque, noi cerchiamo di fare più in fretta, magari tralasciando questa o quella buona norma che richiederebbero qualche oretta in più…
Proprio a questo proposito, nel suo intervento, Adam ha utilizzato l’espressione Responsability to say “NO”.
Sì, perché, in quanto professionisti del settore dello sviluppo software, noi abbiamo la precisa responsabilità di opporci a quelle richieste che sappiamo essere sbagliate.
I nostri clienti o i nostri capi si rivolgono a noi per avere un prodotto che spesso sono in grado di comprendere e giudicare solo in parte. Sta a noi e alla nostra professionalità, fornire loro qualcosa che sia di qualità anche sotto quei punti di vista che loro non posso apprezzare immediatamente.
Se dicessimo al nostro chirurgo che per risparmiare tempo in sala operatoria vogliamo che eviti di lavarsi le mani, pensate che lui ci accontenterebbe? Ovviamente no.
Allo stesso modo, noi non dobbiamo assecondare richieste incompatibili con il lavoro che stiamo andando a svolgere.