Quando si prendono soldi in prestito da una banca o da un investitore, lo si fa perch\u00e9 si vuole fare qualcosa in maniera pi\u00f9 rapida di quanto non si potrebbe fare altrimenti. L\u2019esempio pi\u00f9 comune \u00e8 quello dell\u2019acquisto di una casa; immaginiamo che, per farlo, molti di voi avranno dovuto contrarre un mutuo. Se aveste aspettato di poterla finanziare soltanto coi vostri risparmi, nella migliore delle ipotesi avreste dovuto aspettare la comparsa di qualche capello bianco; nella peggiore, sareste rimasti per sempre in affitto.
\nPrendendo un mutuo, quindi, accettate di avere subito dei soldi da investire in cambio del pagamento di interessi per un certo numero di anni.<\/p>\n
Similmente, quando si deve sviluppare una nuova funzionalit\u00e0 in un sistema software (o magari costruirlo da zero), si ricorre spesso ai dei compromessi sulla qualit\u00e0 del codice scritto, con lo scopo di rilasciare tale funzionalit\u00e0 nel pi\u00f9 breve tempo possibile. I motivi di questa costante rincorsa possono essere disparati: si va dalla necessit\u00e0 di dover essere pronti a fronteggiare una nuova compliance burocratica, alla volont\u00e0 di mettere una funzionalit\u00e0 in mano ai vostri utenti prima che lo faccia un vostro competitor oppure semplicemente perch\u00e8 ogni mese ci sono stipendi e servizi da pagare, e per farlo dobbiamo mettere nelle mani dei nostri venditori un prodotto che sia sempre pi\u00f9 vendibile e per cui sempre pi\u00f9 clienti siano disposti a pagare.
\nMolte aziende del nostro settore vivono purtroppo in uno stato di perpetua fretta: si \u00e8 sempre con l\u2019acqua alla gola e per molte di queste prendere scorciatoie non \u00e8 l\u2019eccezione ma bens\u00ec la regola da seguire sempre.<\/p>\n
In questo capitolo vi vogliamo raccontare il pericolo che si corre operando come un\u2019azienda dove il mantra da seguire \u00e8 quello di prendere tutte le scorciatoie possibili e risparmiare tempo e denaro in qualsiasi situazione, anzich\u00e9 costruire qualcosa con l\u2019intento di durare nel tempo.
\nOgnuno di questi compromessi che scegliamo di seguire porta inevitabilmente con s\u00e9 un insieme di sub-ottimalit\u00e0 che si manifestano nella qualit\u00e0 del codice o della sua documentazione. Giorno dopo giorno, queste vanno a cumularsi con quelle gi\u00e0 precedentemente introdotte nella codebase, andando a prendere parte all\u2019insieme di tutte queste sub-ottimalit\u00e0 che lentamente ed inesorabilmente cresce: questo \u00e8 il debito tecnico.<\/p>\n
Il debito tecnico non deve essere visto come un qualcosa di negativo in termini assoluti, ma bens\u00ec come uno strumento fisiologico per un\u2019azienda che sviluppa software; tutto sta nel saper bilanciare nel modo giusto il suo utilizzo e nell\u2019avere poi la diligenza, quando sar\u00e0 il momento, di fermarsi a sanarlo. La parte difficile \u00e8 proprio quella di capire quando \u00e8 il momento giusto: quanto debito tecnico \u00e8 accettabile? Quando \u00e8 che arriva il momento di fare pausa, respirare e profondamente e scegliere di dedicare il giusto tempo a sanare un po\u2019 di questo deficit?<\/p>\n
Sfortunatamente per noi, non esiste una regola unica per etichettare in modo univoco che cos\u2019\u00e8 e che cosa non \u00e8 debito tecnico: la sua individuazione ha un carattere decisamente soggettivo.
\nPer dirla tutta, da una parte \u00e8 difficile misurare la quantit\u00e0 di debito che viene introdotta ad ogni ciclo di implementazione di nuove funzionalit\u00e0; dall\u2019altra \u00e8 ancora pi\u00f9 complicato avere visibilit\u00e0 circa il debito di cui siamo gi\u00e0 in possesso.
\n\u00c8 facile intuire come la quantit\u00e0 del debito tecnico che introduciamo possa dipendere in gran parte anche dalla qualit\u00e0 del team di sviluppo; tuttavia dobbiamo essere consapevoli che anche il miglior gruppo di ingegneri informatici dovr\u00e0 ricorrere ad una certa quantit\u00e0 di debito tecnico nel suo sviluppo quotidiano.<\/p>\n
Per comprendere bene l\u2019impatto che questo pu\u00f2 avere su di una codebase (e quindi sul business), \u00e8 di fondamentale importanza fare una primissima distinzione tra debito tecnico intenzionale e debito tecnico accidentale.<\/p>\n
Il debito tecnico intenzionale \u00e8 quello \u201cbuono\u201d, cio\u00e8 quello che si contrae in maniera consapevole e allo stesso tempo prudente.
\nPer essere pienamente consapevoli del debito che si \u00e8 deciso di contrarre, \u00e8 necessario che:<\/p>\n
– Il team abbia effettuato un\u2019analisi sui rischi e sulle conseguenze che tale debito pu\u00f2 avere fino a quando non verr\u00e0 ripagato;
\n– Ci si sia fatti un\u2019idea sul \u201ccome\u201d questo debito debba essere rimosso;
\n– Come naturale conseguenza, si abbia un piano su \u201cquando\u201d effettuare questa rimozione.<\/p>\n
I motivi per cui a volte \u00e8 accettabile introdurre del debito tecnico consapevole sono molteplici. Per esempio quando abbiamo sviluppato in Slope la funzionalit\u00e0 \u201ccalendario delle prenotazioni\u201d (planning), abbiamo scelto di implementarlo con un render lato server di una tabella HTML. Questo ha portato con s\u00e9 un grande vantaggio: era la cosa pi\u00f9 veloce che potevamo fare.
\nI clienti ci chiedevano un modo per visualizzare le prenotazioni all\u2019interno di un calendario, e noi dovevamo rendere possibile questa cosa per evitare di perdere preziose quote di mercato (ossia perdere coloro che erano gi\u00e0 clienti ma anche perdere nuove acquisizioni). Quindi abbiamo trovato una soluzione che era veloce da implementare e in linea di massima poteva essere ritenuta soddisfacente per buona parte dei clienti che ci chiedevano la funzionalit\u00e0.<\/p>\n
Abbiamo quindi rilasciato la funzionalit\u00e0 planning sapendo per\u00f2 che portava con s\u00e9 una serie di problemi, alcuni visibili all\u2019utente finale come:
\n– Relativa lentezza di caricamento;
\n– Necessit\u00e0 di ricaricare la pagina ogni volta che si faceva una modifica, che contribuiva a peggiorare l\u2019usabilit\u00e0;
\n– Limite del numero di risorse che potevano essere visualizzate a schermo.<\/p>\n
Ma i problemi non finivano qui, dal punto di vista tecnico ingegneristico:
\n-Avevamo una non testabilit\u00e0 del codice attraverso test unitari, dovevamo ricorrere solo a test funzionali;
\n– Il codice della template della pagina era molto articolato, complesso da leggere e modificare: ogni intervento da parte di un ingegnere richiedeva attenzione chirurgica, perch\u00e9 la probabilit\u00e0 di\u00a0 \u00a0 \u00a0 \u00a0 -Rompere qualcosa era piuttosto elevata.
\n-Potremmo continuare cos\u00ec ancora per un po\u2019, ma probabilmente avete gi\u00e0 capito il concetto.<\/p>\n
Il calendario delle prenotazioni era stato comunque implementato (in poco tempo) e potevamo finalmente annunciarlo ai nostri clienti e prospect. Giunti a questo punto, per\u00f2, sapevamo tutti che questa sarebbe stata una soluzione relativamente temporanea: avremmo dovuto collezionare feedback e metriche di utilizzo per poi riprogettare il componente da zero.<\/p>\n
Qui arriva la parte difficile, cio\u00e8 quella in cui per esperienza sappiamo che molte aziende sbagliano. Anzich\u00e9 avere la consapevolezza che un determinato ramo di codice non pu\u00f2 essere espanso in modo efficiente e scalabile, decidono di continuare a svilupparci sopra comunque.
\n\u201cAggiungiamo questa piccola funzionalit\u00e0 al planning, non \u00e8 niente di ch\u00e8, cosa da poco\u201d, oppure
\n\u201cAggiungiamo quest\u2019altra cosa che ci stanno chiedendo molti clienti, un paio di giorni di lavoro e li facciamo contenti\u201d e cos\u00ec via, funzionalit\u00e0 sopra funzionalit\u00e0, si accumula debito tecnico con tassi di interessi da usura.
\nSi arriva infatti ad un punto in cui si \u00e8 investito talmente tanto tempo e denaro per costruire funzionalit\u00e0 sopra a un codice subottimale, che tornare indietro non \u00e8 pi\u00f9 un\u2019opzione. Cos\u00ec i nostri cicli di sviluppo e di rilascio si rallentano, il codice diventa sempre meno comprensibile e manutenibile: ci\u00f2 che ne risente \u00e8 ovviamente la bont\u00e0 del prodotto finale, quella che percepisce il cliente.<\/p>\n
Un\u2019azienda tech first non pu\u00f2 cadere questo tranello e dopo pi\u00f9 di un anno di glorioso servizio abbiamo deciso di riscrivere la funzionalit\u00e0 di planning con una nuova tecnologia che era in grado di soddisfare a pieno i requisiti di prodotto e tecnici che ci eravamo posti dopo aver misurato l\u2019utilizzo della funzionalit\u00e0 precedente.<\/p>\n
Abbiamo pensionato senza alcuna nostalgia quel codice che era stato sviluppato in poco tempo e su quale non abbiamo investito granch\u00e9, e lo abbiamo sostituito con un\u2019applicazione nuova, sviluppata senza pressioni di deadline ma soprattutto seguendo una specifica di prodotto chiara: sapevamo esattamente che cosa volevano i clienti e che cosa avremmo dovuto fare.<\/p>\n
La riscrittura di un ramo del codice di un\u2019applicazione \u00e8 un processo abbastanza drastico; ci piaceva portarlo come esempio perch\u00e9 \u00e8 stata una decisione che oggi, a posteriori, riteniamo ovvia ma durante la fase di scelta e decisione \u00e8 stata un po\u2019 sofferta (buttare nel cestino qualcosa che \u201cfunziona\u201d non \u00e8 mai facile da far capire a tutti i membri del team, specialmente ai meno tecnici).
\nOltre alla totale riscrittura di un blocco funzionale (cosa che, ripetiamo, dovrebbe essere un\u2019eccezione e non la regola) \u00e8 ovviamente possibile, e soprattutto pi\u00f9 gestibile, ridurre il debito tecnico anche in dosi pi\u00f9 piccole, e cio\u00e8 attraverso l\u2019attivit\u00e0 di refactoring continuo.
\nIn base ai piani e alla disponibilit\u00e0 degli sviluppatori, questa attivit\u00e0 di refactoring \u201cbonificatore\u201d pu\u00f2 essere pianificata o appena dopo il rilascio, oppure deve essere messa in conto come prerequisito per uno sviluppo futuro che andr\u00e0 ad agire sulle stesse parti di codice, o su parti limitrofe.
\nA questo proposito dobbiamo considerare che, in generale, la quantit\u00e0 di tempo e di fatica mentale necessaria per rifattorizzare codice oggetto di debito tecnico sar\u00e0 tanto pi\u00f9 alta quanto tempo si fa passare tra l\u2019introduzione di quest\u2019ultimo e, appunto, il refactoring.
\nQuesto succede tipicamente per due motivi principali:
\n-Dopo un po\u2019 di tempo lo sviluppatore si dimentica dei dettagli, sia tecnici che concettuali, relativi ad una determinata funzionalit\u00e0 e a come \u00e8 stata implementata;
\n-La naturale tendenza di ogni codebase \u00e8 quella di espandersi e complicarsi con il tempo, per cui ad ogni nuova aggiunta di codice c\u2019\u00e8 il rischio di avere un potenziale ostacolo in pi\u00f9 da \u201csaltare\u201d\u00a0 \u00a0 \u00a0 \u00a0 -Quando il momento del refactoring arriver\u00e0.<\/p>\n
Il nostro consiglio \u00e8 quindi quello di cercare di non procrastinare troppo, e di allocare regolarmente tempo nei vostri planning settimanali per attivit\u00e0 di refactoring al fine di rimuovere debito tecnico nel modo pi\u00f9 efficiente e meno oneroso possibile.<\/p>\n
Ben pi\u00f9 problematico rispetto al debito tecnico intenzionale vi \u00e8 invece il debito tecnico cosiddetto accidentale, cio\u00e8 quello che viene introdotto senza per\u00f2 avere consapevolezza che che lo si sta introducendo.
\nAlcuni esempi illustri di situazioni che generano debito tecnico accidentale possono essere:
\ncarenza di persone qualificate nel team di sviluppo
\nalto ricambio di personale
\ncodice in outsourcing
\nscarsit\u00e0 di documentazione nel codice esistente
\nprocesso di sviluppo non strutturato<\/p>\n
In generale, un team di sviluppo non coeso, che quindi non lavora all’unisono verso una direzione comune, sar\u00e0 pi\u00f9 propenso ad introdurre debito tecnico. Anche la motivazione del singolo gioca un ruolo importante: se l\u2019individuo non ha interesse a fare il bene del prodotto e dell’azienda, sceglier\u00e0 sempre la strada pi\u00f9 breve per svolgere qualunque compito.
\nIn realt\u00e0, questa regola vale per qualsiasi dipartimento e non solo per l\u2019ingegneria. Il problema nell\u2019ambito ingegneristico per\u00f2 pu\u00f2 manifestarsi con maggiore gravit\u00e0, visto che il debito introdotto ha un peso che durer\u00e0 per tutta la vita del prodotto, o almeno fino a che non verr\u00e0 dedicato del tempo per rimuoverlo; altri dipartimenti hanno la \u201cfortuna\u201d di avere un impatto pi\u00f9 o meno forte, ma probabilmente meno duraturo nel tempo.<\/p>\n
Inoltre, secondo la nostra esperienza, tanto debito tecnico che nasce come intenzionale finisce inevitabilmente per diventare accidentale: questo succede spesso nelle aziende di software che non sono tech driven, oppure quelle che sono sotto costante pressione da parte del mercato o dei propri investitori per rilasciare continuamente nuove funzionalit\u00e0.<\/p>\n
Anche per questa ragione \u00e8 di fondamentale importanza che il processo di decision making di un\u2019azienda di software tenga in considerazione anche la voce dell\u2019ingegneria. Sar\u00e0 compito di questo dipartimento rendere chiara la necessit\u00e0 di considerare il refactoring come naturale precondizione di sviluppi ulteriori.<\/p>\n
\u00c8 spaventoso pensare come il debito tecnico diventi estremamente dannoso anche nel contesto del recruiting e retention dei talenti. Nessuno ha piacere a lavorare in un ambiente caotico e disorganizzato, allo stesso modo nemmeno su di una codebase stracolma di debito tecnico.
\nQuesto perch\u00e9 il lavoro di sviluppo su una piattaforma indebitata \u00e8 complesso, faticoso e molto poco gratificante: si spende buona parte del tempo ad applicare toppe a problemi che non si riescono a risolvere in maniera definitiva, le cose vanno a rilento e la frustrazione regna sovrana.<\/p>\n
Un\u2019altra importante considerazione da fare, \u00e8 che mentre il debito finanziario, quello che un\u2019azienda ha nei confronti di banche e investitori, \u00e8 misurabile facilmente e soprattutto in maniera oggettiva.
\nIl debito che si ha nei confronti della tecnologia, invece, \u00e8 molto pi\u00f9 difficile da identificare e quantificare; tuttavia, il fatto che questo tipo di debito sia meno visibile e immediato non significa che possa essere ignorato e, anzi, \u00e8 proprio questo il fattore che lo rende estremamente pericoloso.<\/p>\n
L\u2019impatto che porta con s\u00e9 uno stile di sviluppo che tende ad accumulare debito tecnico \u00e8 trasversale:
\nnel tempo impatta inesorabilmente la velocit\u00e0 di sviluppo che viene rallentata progressivamente;
\nfa perdere competitivit\u00e0 all\u2019azienda poich\u00e9 il prodotto far\u00e0 difficolt\u00e0 ad essere innovato e migliorato;
\ncausa frustrazione del personale e dei membri del team.<\/p>\n","protected":false},"excerpt":{"rendered":"
Che cos\u2019\u00e8 il debito tecnico Quando si prendono soldi in prestito da una banca o da un investitore, lo si fa perch\u00e9 si vuole fare qualcosa in maniera pi\u00f9 rapida di quanto non si potrebbe fare altrimenti. L\u2019esempio pi\u00f9 comune \u00e8 quello dell\u2019acquisto di una casa; immaginiamo che, per farlo, molti di voi avranno dovuto […]<\/p>\n","protected":false},"author":1,"featured_media":45,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-59","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/posts\/59","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/comments?post=59"}],"version-history":[{"count":1,"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/posts\/59\/revisions"}],"predecessor-version":[{"id":61,"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/posts\/59\/revisions\/61"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/media\/45"}],"wp:attachment":[{"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/media?parent=59"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/categories?post=59"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.techfirst.blog\/index.php\/wp-json\/wp\/v2\/tags?post=59"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}