Nel mio precedente articolo ho parlato di Debito tecnico. Abbiamo paragonato il team di sviluppo ad una squadra di calcio, con tutti quelli che sono i possibili limiti di un gruppo non ancora pronto per affrontare una stagione al di sopra delle proprie possibilità. Vero, ma la forza di un team non deriva dalla mera sommatoria delle capacità dei singoli. Al contrario, si riscontra nella capacità di far gruppo, giocare di squadra e condividere risorse.
Torniamo di fronte ai nostri schermi. Abbiamo un progetto complesso: righe e righe di codice, chilometrici file di properties e modifiche da portare a termine. Anche un solo update, se non supportato da documentazione aggiornata, tempistiche adeguate o da tutte quelle cause del Debito tecnico già affrontate, può mandare in tilt il team di sviluppo, soprattutto se i singoli giocatori continuano a giocare su schermi a compartimenti stagni.
Come affrontarlo? Torniamo al concetto di Debito tecnico secondo la definizione di Ward Cunningham.
“il debito tecnico è il lavoro che deve essere ancora fatto per poter considerare totalmente completata una singola attività di sviluppo. Quando si inizia una modifica ad un progetto software, spesso devono essere apportate altre modifiche coordinate in altre parti di codice, nella documentazione ecc… Le modifiche richieste, ma non completate, sono considerate debito tecnico, che dovrà essere pagato prima o poi in futuro.”
Più un progetto è complesso, più è difficile tenere le fila della programmazione. Alla crescita del progetto – in termini di file da gestire, processi da implementare e database da progettare – corrisponde la quasi impossibilità di azzerare il Debito tecnico. La consapevolezza del Debito tecnico come male irrinunciabile è il primo presupposto per affrontarlo con la dovuta attenzione. Guai a perderlo di vista. Il Debito tecnico infatti, come ogni altro tipo di debito, genera interessi. Più si posticipa un pagamento (o in questo caso la risoluzione del problema), più alta diventa la quantità di lavoro necessaria per ripagarlo (o risolverlo). Ciò avviene a causa della scarsa organizzazione che il lavoro mancante sta generando.
Come ridurre, pertanto, il Debito tecnico? Giocando di squadra. Comunicando.
La relazione come upgrade dello sviluppo
I team devono auto-imporsi schemi di comunicazione, strumenti che agevolino lo scambio fra gli sviluppatori e l’interpretazione del codice nel tempo. Torniamo alla metafora calcistica: nessuna squadra potrebbe reggere l’impatto della serie A se in campo vi fosse completa anarchia tattica.
Il codice sviluppato da un team che non comunica correttamente eredita nelle sue righe tutti i difetti di una relazione complicata. Pagine che non si parlano, classi o procedure con nomi poco intelligibili, muri di codice che fanno desistere anche il più volenteroso degli sviluppatori.
Definire a monte partitura e regole d’interazione è una prima strategia per ridurre il Debito tecnico. Un codice parlante e chiaro semplifica la manutenzione, permette a più sviluppatori del team di intervenire per correggere bug e implementare nuove features e, soprattutto, non trasforma il debug in una sfiancante ricerca del Sacro Graal.
Come ridurre il debito tecnico: partiamo dalla scrittura del codice
Una buona parte degli accorgimenti può essere messa in pratica nella stesura del codice stesso.
Un’impaginazione corretta del codice – indentazioni, spaziature fra porzioni di codice omogenee – è un primo consistente aiuto per agevolare la lettura e la comprensione dello stesso.
Condividere a tavolino una nomenclatura di variabili, oggetti, metodi, funzioni e regole per la composizione di ogni nuovo nome è utile per rendere il codice più vicino al linguaggio umano, evidenziare l’obiettivo di ogni componente e condividere fra gli sviluppatori la stessa lingua progettuale.
Definire metodologie e linee guida appropriate per la scrittura dei messaggi di errore è strategico sia per i suoi risvolti sulla UX sia in fase di sviluppo. Un messaggio criptico, in assenza di documentazione allineata con lo stato d’avanzamento del progetto, rende ancora più difficile replicare l’errore in ambiente di sviluppo e di conseguenza comprenderne le cause. Messaggi di errori scritti in maniera chiara e intelligibile aiutano anche gli sviluppatori: permettono di replicare facilmente l’errore e, se necessario, intervenire senza ambiguità, in tempi rapidi.
Infine, la cara, vecchia e ottima abitudine di commentare il codice secondo regole stabilite a priori permette agli sviluppatori “smemorati” e a quelli che subentreranno nel team di ricordarlo e comprenderlo più facilmente. La scrittura di un breve paragrafo introduttivo all’interno del codice permetterà in futuro di risparmiare intere giornate passate davanti all’inspector per capire il destino delle variabili fra cicli e colli di bottiglia del codice.
Come ridurre il Debito tecnico a progetto avviato
Portiamo a casa la convinzione che scrivere bene il codice e favorire la comunicazione all’interno del team sia un ottimo punto di partenza. Ma come procedere quando ereditiamo un progetto con un discreto Debito tecnico? Riscrivere ex novo il codice non è (quasi) mai la soluzione migliore, perché toglie tempo ed energie utili per nuovi sviluppi e, soprattutto, rischia di compromettere il lavoro già consolidato, di generare ulteriori bug e di sottrarre al prodotto features implicite di difficile ricostruzione.
Il buonsenso, in questo caso, ci aiuta. Anche qui torniamo al calcio. Se sulla panchina della nostra squadra di serie A subentrasse un nuovo allenatore, difficilmente una rivoluzione da zero porterebbe subito nuovi risultati. Ci sono equilibri interni da mantenere e processi – allenamento, schemi, gestione del gruppo – sui quali mettere mano un passo alla volta.
Dovremmo fare lo stesso ragionamento anche con il nostro progetto software: eseguire modifiche in modo graduale.
1. Cominciare per gradi appunto. Invece di riscrivere il progetto da zero, adottiamo le buone pratiche sul codice nuovo. Riscriviamo anche le parti di codice che vengono usate più frequentemente. Salvaguardiamo infine la parte core più datata, per evitare che correzioni sostanziali al codice possano compromettere il funzionamento consolidato dell’applicativo.
2. Code Inspection. Analizziamo costantemente il codice e la documentazione per verificare i punti deboli in termini di performance, sicurezza, scrittura e chiarezza del codice.
3. Fissare una tabella di marcia. Il punto più cruciale è creare una nuova cultura aziendale, un nuovo spirito di squadra con dei piccoli riti quotidiani che siano in grado di scandire la giornata lavorativa.
Istituzionalizzare le relazioni fra gli sviluppatori significa abituare le persone a non lavorare a compartimenti stagni ma a guardare il progetto nel suo insieme.
Fin qui abbiamo visto come ridurre il debito tecnico adottando buone pratiche durante lo sviluppo o intervenendo successivamente, a lavoro fatto. Ma non sarebbe meglio eliminare il problema all’origine? Ne parliamo prossimamente sul nostro blog.
