{"id":255853,"date":"2023-03-02T06:48:00","date_gmt":"2023-03-02T03:48:00","guid":{"rendered":"https:\/\/inform.click\/come-valutare-gestire-ed-evitare-debiti-tecnici\/"},"modified":"2023-03-02T07:42:00","modified_gmt":"2023-03-02T04:42:00","slug":"come-valutare-gestire-ed-evitare-debiti-tecnici","status":"publish","type":"post","link":"https:\/\/inform.click\/it\/come-valutare-gestire-ed-evitare-debiti-tecnici\/","title":{"rendered":"Come valutare, gestire ed evitare debiti tecnici"},"content":{"rendered":"

\n Se il debito tecnico suona come qualcosa preso da un manuale di finanza, \u00e8 perch\u00e9 il termine \u00e8 legato alla finanza. Tuttavia, nel vero senso della parola, il debito tecnico \u00e8 legato alla programmazione. \u00c8 l'idea che durante lo sviluppo di un progetto software, alcuni passaggi necessari vengano saltati o semplicemente abbandonati del tutto nel tentativo di rispettare una scadenza.\n<\/p>\n

\n Nel tentativo di sviluppare l'app o il software perfetto, gli sviluppatori sono spesso a corto di tempo, proprio come qualsiasi persona a caso che svolge comunque un compito arbitrario. Pertanto, di solito ha senso avere una sorta di compromesso tra la consegna di un prodotto perfetto con un codice perfetto e la massimizzazione del tempo.\n<\/p>\n

\n La domanda allora \u00e8: c'\u00e8 un limite a questi compromessi? Ci sono danni intrinseci che potrebbero derivare da questo compromesso? Infine, lo sviluppatore sta davvero meglio a lungo termine? In questo pezzo sui debiti tecnici, cercher\u00f2 di rispondere a tutte queste domande.\n<\/p>\n

\n Cos'\u00e8 il debito tecnico?
\n<\/h5>\n

\n Nel definire il debito tecnico, dovremo fare riferimento all'uomo a cui si attribuisce in primo luogo di aver generato il termine: Ward Cunningham. Secondo Cunningham, il debito tecnico si riferisce al lavoro di sviluppo extra che deve essere svolto nella programmazione di un codice per compensare il deficit derivante dalla sua programmazione in un breve periodo.\n<\/p>\n

\n Per renderlo pi\u00f9 grafico, immagina di avere il compito di ripulire una stanza disordinata e di essere in ritardo per una lezione. Nel tentativo di assicurarti di eseguire le istruzioni e anche di essere puntuale per la tua lezione, fai una rapida pulizia, spazzando la maggior parte dei detriti sotto il divano. La ricaduta di questo \u00e8 che alla fine dovrai prenderti il \u200b\u200btempo per sistemare il casino. Per lo sviluppo del software, quando salti i passaggi necessari e segui un percorso pi\u00f9 semplice, con codici “non cos\u00ec puliti”, diventer\u00e0 pi\u00f9 difficile ripulire il codice in futuro. Ci sono pi\u00f9 fasi incontrate nei domino del progetto software e pi\u00f9 a lungo ignori un problema esistente, pi\u00f9 tempo ci vorr\u00e0 per risolverlo.\n<\/p>\n

\n Tipi di debiti tecnici\n<\/p>\n

\n I debiti tecnici sono di diverse tipologie, tra cui:\n<\/p>\n

\n Debiti tecnici pianificati
\n<\/h5>\n

\n Ci\u00f2 si verifica in situazioni in cui le organizzazioni decidono deliberatamente di contrarre debiti tecnici. Questo, come discusso in precedenza, \u00e8 solitamente quello di superare le scadenze stabilite e arrivare a un obiettivo specifico. Quando si impegnano in debiti tecnici pianificati, l'organizzazione deve essere chiara a cosa \u00e8 disposta a rinunciare ea cosa non pu\u00f2. Devi tenere registri accurati, tenendo presente che alla fine dovrai tornare e correggere gli errori che hai saltato all'inizio.\n<\/p>\n

\n Debiti tecnici non intenzionali
\n<\/h5>\n

\n Questo tipo di debito tecnico \u00e8 l'esatto opposto del primo. Si verifica quando un'organizzazione non prevede o pianifica il debito tecnico. La ragione di ci\u00f2 \u00e8 in genere un'interruzione della comunicazione tra le varie unit\u00e0 dell'organizzazione o pratiche di lavoro scadenti tra le unit\u00e0.\n<\/p>\n

\n Debiti tecnici inevitabili
\n<\/h5>\n

\n Questo \u00e8 il tipo di debito tecnico che nessuna azione da parte dell'organizzazione avrebbe potuto evitare. Ad esempio, con i rapidi cambiamenti sperimentati nella tecnologia, ha senso che alcuni codici scritti in passato non siano all'altezza degli attuali standard previsti.\n<\/p>\n

\n Inoltre, questo tipo di debito tecnico pu\u00f2 sorgere quando vengono richieste modifiche quando il codice \u00e8 gi\u00e0 in fase di scrittura. Se a met\u00e0 della progettazione del software vengono introdotte alcune modifiche, potrebbero incasinare le dinamiche, rendendo il vecchio codice obsoleto o non necessario.\n<\/p>\n

\n Cause del debito tecnico
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Alcuni dei motivi del debito tecnico sono stati discussi in precedenza, ma li selezioner\u00f2 uno dopo l'altro per renderli pi\u00f9 chiari.\n<\/p>\n

\n Fretta
\n<\/h5>\n

\n La causa pi\u00f9 frequente di indebitamento tecnico \u00e8 la fretta. Gli sviluppatori hanno spesso scadenze rigorose, alcune delle quali includono scadenze per il lancio di determinati software. \u00c8 spesso comprensibile (e prevedibile) in questo tipo di situazioni che lo sviluppatore possa incorrere in debiti tecnici lungo il percorso. Questo tipo di debito tecnico \u00e8 spesso intenzionale e pu\u00f2 comportare problemi che potrebbero variare dall'avere bug nel codice o insorgere di spaghetti code.\n<\/p>\n

\n Svista\/errore
\n<\/h5>\n

\n A volte, i programmatori scrivono solo codici errati, che alla fine portano a debiti tecnici. Indipendentemente dal fatto che il codice errato esista a causa dell'errore del programmatore o meno, il fatto \u00e8 che gli errori si traducono in debiti tecnici e, poich\u00e9 non sono scalabili, alla fine dovranno essere corretti.\n<\/p>\n

\n Mancanza di consapevolezza degli effetti
\n<\/h5>\n

\n A volte i debiti tecnici sorgono perch\u00e9 il codificatore non riesce a rendersi conto o riconoscere quanto dannosi siano i debiti tecnici a lungo termine. Ci\u00f2 potrebbe derivare da una legittima ignoranza degli effetti dannosi di prendere scorciatoie durante la programmazione, oppure potrebbe essere un intenzionale disprezzo delle conseguenze.\n<\/p>\n

\n Intenzione
\n<\/h5>\n

\n I debiti tecnici possono sorgere intenzionalmente dalle azioni deliberate del codificatore o dell'organizzazione.\n<\/p>\n

\n Mancanza di modularit\u00e0
\n<\/h5>\n

\n Ci\u00f2 si verifica principalmente perch\u00e9 un codice pu\u00f2 servire diverse logiche di business contemporaneamente. Questo tipo di situazione rende la gestione del software molto pi\u00f9 difficile. Con ogni codice scritto da uno sviluppatore, maggiori sono le possibilit\u00e0 che sperimentino sfide con la modularit\u00e0.\n<\/p>\n

\n Valutazione del debito tecnico
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n I debiti tecnici non dovrebbero mai essere calcolati manualmente perch\u00e9 sarebbe piuttosto arduo. Significherebbe dover inserire manualmente il codice per determinare i problemi attuali e quelli possibili futuri. A parte quanto sia dispendioso in termini di tempo il processo manuale, esiste la possibilit\u00e0 che i codici abbiano cambiato forma alla fine del processo manuale.\n<\/p>\n

\n Un modo per eseguire la valutazione \u00e8 eseguire un'analisi statica utilizzando alcuni strumenti che la supportano. Alcuni degli strumenti che possono essere utilizzati includono Coverity, SonarQube, Check Style e Closure Compiler.\n<\/p>\n

\n In generale, ci sono due modi per calcolare i debiti tecnici. Nel primo approccio, potrebbe essere ottenuto calcolando il rapporto del debito tecnico dopo il rapporto di codice. Qui, la stima iniziale o il tempo complessivo necessario per sviluppare l'app verrebbero utilizzati per determinare il tempo necessario per riparare il debito tecnico.\n<\/p>\n

\n Nel secondo approccio, potresti utilizzare direttamente le stime fornite dai vari strumenti come SonarQube. A questo saranno abbinati gli elenchi dei debiti tecnici nonch\u00e9 i loro codici di riferimento. Dagli strumenti \u00e8 possibile ottenere una stima accurata del tempo necessario per risolverlo.\n<\/p>\n

\n Valutare il debito tecnico ti dar\u00e0 un'idea di quanti giorni ci vorranno per riparare il debito tecnico. Pi\u00f9 debiti ci sono, pi\u00f9 tempo ci vorr\u00e0 per risolverlo.\n<\/p>\n

\n Risoluzione dei debiti tecnici
\n<\/h3>\n

\n Cosa succede se si sono verificati debiti tecnici e non sai cosa fare? Ci sono alcuni passi che puoi fare per gestire i debiti tecnici.\n<\/p>\n

\n In primo luogo, dovresti riconoscere che i debiti tecnici esistono e comunicarli al tuo team. Nella comunicazione, dovresti essere chiaro su cosa \u00e8 successo e cosa \u00e8 necessario fare per correggerlo. Dovresti assicurarti di comunicare chiaramente la necessit\u00e0 di occuparti del debito tecnico il prima possibile.\n<\/p>\n

\n Dopo aver informato il tuo team dei debiti tecnici, ci sono tre approcci che potresti adottare. Nel primo approccio, potresti decidere di continuare con il sistema cos\u00ec com'\u00e8. In questo scenario, l'applicazione verr\u00e0 utilizzata cos\u00ec com'\u00e8.\n<\/p>\n

\n In alternativa, potresti decidere di eseguire il refactoring dell'applicazione. Il refactoring viene eseguito con l'obiettivo di ridurre la complessit\u00e0 nell'app e di ripulire la struttura dell'app. Con il refactoring, il comportamento del software non verr\u00e0 modificato; l'unica parte interessata sar\u00e0 la struttura interna.\n<\/p>\n

\n Infine, se le due opzioni discusse sopra non funzionano, dovrai sostituire completamente il codice. Un problema con questo \u00e8 che potrebbe portare a nuovi debiti tecnici, ma potrebbe essere un compromesso migliore a lungo termine.\n<\/p>\n

\n Evitare debiti tecnici in futuro
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Ovviamente, \u00e8 un gioco da ragazzi che evitare i debiti tecnici sia decisamente pi\u00f9 intelligente che cercare di risolverli quando si presentano. A parte il fatto che ti fa risparmiare tempo e stress, fa anche in modo che le conseguenze residue che derivano dall'avere debiti tecnici fin dall'inizio siano assenti.\n<\/p>\n

\n Si potrebbe sostenere che i debiti tecnici, di per s\u00e9, non sono un male. Sono generalmente problematici perch\u00e9 sono debiti che devono essere ripagati e gli umani non sono la specie pi\u00f9 responsabile sulla terra. La scelta costante di un'opzione pi\u00f9 debole generalmente indebolir\u00e0 la forza del tuo software e render\u00e0 pi\u00f9 difficile migliorare le funzionalit\u00e0 in seguito. In tutto, evitare i debiti tecnici \u00e8 la soluzione migliore per chiunque.\n<\/p>\n

\n Quindi, come evitare che sorgano debiti tecnici:\n<\/p>\n

\n Crea un arretrato di progetto\n<\/p>\n

\n L'idea qui \u00e8 di tenere tutti al passo con il processo e portarli al passo con i requisiti per qualsiasi compito venga svolto. La creazione di un backlog consente a tutti di vedere le attivit\u00e0 lasciate in sospeso e i percorsi da intraprendere per raggiungerle.\n<\/p>\n

\n Dai la priorit\u00e0 alla qualit\u00e0 rispetto alla velocit\u00e0\n<\/p>\n

\n Se sei tu stesso un programmatore, devi imparare a dare la priorit\u00e0 alla realizzazione di un lavoro di qualit\u00e0 rispetto a molto lavoro. Assicurati che i tuoi codici siano puliti e che le tue app o altri software siano sviluppati alla perfezione. Comprendi che la tentazione di prendere scorciatoie non varr\u00e0 la pena perch\u00e9 alla fine dovrai comunque svolgere i compiti che hai abbandonato.\n<\/p>\n

\n Se sei a capo di un team, devi comunicare questi stessi valori ai membri del team. Ai membri dovrebbe essere insegnato a creare soluzioni orientate ai risultati ed evitare le scorciatoie.\n<\/p>\n

\n Sensibilizzare\n<\/p>\n

\n In generale, una conoscenza approfondita di cosa sia il debito tecnico e di come evitarlo pu\u00f2 essere utile in primo luogo per prevenirne l'insorgenza. Quando fornisci ai tuoi sviluppatori le conoscenze necessarie, eviteranno meglio le trappole poste dai debiti tecnici.\n<\/p>\n

\n Introdurre buone pratiche di programmazione\n<\/p>\n

\n Alcune pratiche di codifica rendono pi\u00f9 probabile che tu non cada in un debito tecnico. Pertanto, sarebbe bello evitare l'accoppiamento stretto, impiegare l'astrazione e il refactoring.\n<\/p>\n

\n Introduci la tecnologia aggiornata\n<\/p>\n

\n Gli aggiornamenti regolari della tecnologia possono essere un ottimo mezzo per prevenire i debiti tecnici. Durante l'aggiornamento, \u00e8 necessario assicurarsi che ci\u00f2 che viene utilizzato sia il framework, i database e il software applicativo pi\u00f9 recenti.\n<\/p>\n

\n Conclusione
\n<\/h5>\n

\n I debiti tecnici, nella stragrande maggioranza dei casi, sono inevitabili finch\u00e9 si continua a sviluppare programmi e scrivere codici. Tuttavia, le possibilit\u00e0 che si verifichino possono essere notevolmente ridotte quando vengono seguiti i passaggi sopra elencati. Inoltre, nell'eventualit\u00e0 di debiti tecnici, ogni speranza non \u00e8 persa. Mantieni la calma, sii fiducioso, agisci di conseguenza.\n<\/p>\n<\/p>\n

\n Fonte di registrazione: instantshift.com<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Se il debito tecnico suona come qualcosa preso da un manuale di finanza, \u00e8 perch\u00e9 il termine \u00e8 legato alla finanza. Tuttavia, nel vero senso della parola, il debito tecnico \u00e8 legato alla programmazione. \u00c8 l’idea che durante lo sviluppo di un progetto software, alcuni passaggi necessari vengano saltati o semplicemente abbandonati del tutto nel tentativo di rispettare una scadenza. Nel tentativo di sviluppare l’app o il software perfetto, gli sviluppatori sono spesso a corto di tempo, proprio come qualsiasi persona a caso che svolge comunque un compito arbitrario. Quindi, di solito ha senso avere una sorta di…<\/p>\n","protected":false},"author":1,"featured_media":209172,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[212,264,95,56],"tags":[],"class_list":["post-255853","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-codifica","category-psicologia-2","category-seo-e-marketing","category-web-e-wordpress"],"_links":{"self":[{"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/posts\/255853","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/comments?post=255853"}],"version-history":[{"count":0,"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/posts\/255853\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/media\/209172"}],"wp:attachment":[{"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/media?parent=255853"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/categories?post=255853"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inform.click\/it\/wp-json\/wp\/v2\/tags?post=255853"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}