Karma negativo nella programmazione. Cos’è il debito tecnico e come risolverlo

Debito tecnico. La maggior parte dei programmatori che lavorano attivamente nella propria specialità devono affrontare questo termine. Per molti, la sua menzione può causare anche mal di testa, così come il disagio in altre parti del corpo che appare ogni volta che si affronta un debito tecnico mentre si lavora a un progetto. Oggi parleremo quindi del debito tecnico (TD): cos’è, come si presenta, quali tipologie di debito tecnico esistono e come gestirlo in modo efficace.

Cos’è il debito tecnico?

Tuttavia, prima comprendiamo la terminologia. Il debito tecnico è una metafora dell'ingegneria del software per i problemi accumulati nel codice o nell'architettura del software a causa della negligenza della qualità nello sviluppo del software e che causano costi di manodopera aggiuntivi in ​​futuro. Questa è la definizione di debito tecnico data da Wikipedia. Per dirla semplicemente, il debito tecnico è il risultato dell’applicazione di soluzioni semplificate e a breve termine nello sviluppo, che successivamente portano a costi sempre crescenti (a meno che, ovviamente, il debito non venga “ripagato”) in termini di denaro e tempo per il successivo perfezionamento, riscrivere il codice o mantenere il prodotto nella sua forma esistente. Nel mondo dei normali programmatori, il debito tecnico è uno dei tipi di karma negativo, un demotivatore e una fonte di tristezza che arriva come punizione per un cattivo codice, l'uso di stampelle e soluzioni "temporanee" (ma in realtà non molto) che contribuire a risolvere i problemi a breve termine e ad accelerare lo sviluppo “a credito”, cioè a scapito di un crescente groviglio di problemi futuri. Nel settore IT, il debito tecnico è un problema abbastanza serio. Secondo uno studio recente , le aziende di tutto il mondo spendono ogni anno più di 85 miliardi di dollari solo per correggere codici errati. In totale, circa 300 miliardi di dollari all’anno vengono spesi in progetti relativi al supporto di sistemi obsoleti e software “cattivi”. Questi sono numeri significativi. I ricercatori stimano che se gli sforzi di tutti gli sviluppatori che lavorano con il debito tecnico e le sue conseguenze fossero concentrati nuovamente sullo sviluppo “giusto”, si aggiungerebbero circa 3 trilioni di dollari al PIL globale nel corso dell’attuale decennio.

Ragioni per l'apparenza

Bisogna capire che il debito tecnico non è sempre una cosa negativa, così come indebitarsi finanziariamente può essere positivo se, ad esempio, si chiede un prestito per sviluppare un'impresa (o avviare una startup ). Nel caso di TD, questo è accettabile per le aziende in rapida crescita che hanno bisogno di rilasciare nuovi prodotti o servizi rapidamente e spesso per valutare il loro successo e studiare le esigenze del mercato, o acquisire rapidamente nuove nicchie, ad esempio. Ma, come con il debito finanziario, anche con il debito tecnico bisogna stare attenti e sapere come gestirlo, altrimenti possono sorgere problemi seri. Maggiore è il debito tecnico accumulato durante lo sviluppo di un prodotto software, più questo può incidere sull’azienda, rallentando il rilascio di nuove versioni, abbassando il morale dei normali programmatori responsabili del “mantenimento” di tale debito e aumentando i costi. , che alla fine può addirittura distruggere l'azienda. Le ragioni del verificarsi di un debito tecnico, oltre al nobile desiderio di completare il prodotto il prima possibile o di accontentare gli utenti con una nuova versione, sono spesso una cattiva gestione del prodotto, scadenze non realistiche o limitazioni delle risorse e, naturalmente, la pigrizia del programmatore. , insieme alle scarse qualifiche e alla mancanza di comprensione dei principi chiave dello sviluppo, spesso contribuiscono anche alla crescita del debito. Accade spesso che gli stessi sviluppatori siano ben consapevoli della presenza e della costante crescita del debito tecnico, ma non abbiano abbastanza potere per cambiarlo, o non possano trasmettere informazioni al management sull'esistenza di un tale problema e sull'importanza di risolverlo.

Classificazione

Come accennato in precedenza, il debito tecnico si presenta in molte forme diverse e, poiché la definizione stessa è solo una metafora, i diversi tipi di debito tecnico possono essere classificati in modi diversi. In particolare, Dag Liodden, co-fondatore e CTO di Tapad, considerato uno degli esperti mondiali di debito tecnico, durante un intervento all'evento annuale CTO Summit, ha proposto di dividere il debito tecnico in tre tipologie principali.

1. Debito tecnico intenzionale.

   Appare nei casi in cui gli sviluppatori scelgono deliberatamente la soluzione migliore, perché è più facile e veloce da implementare, il che, a sua volta, aiuterà a rilasciare rapidamente un nuovo prodotto sul mercato.

   “A volte ci assumiamo deliberatamente un debito tecnico per ridurre i tempi di sviluppo. Se decidi di intraprendere questa strada, considera non solo il tempo che risparmierai durante lo sviluppo, ma anche il tempo che dovrai dedicare in seguito per “pagare” tale debito. Inoltre, assicurati che le parti interessate [il top management dell’azienda] siano consapevoli che tale decisione rallenterà inevitabilmente il lancio di altre funzioni in futuro”, ha affermato Dag Ljodden.

   Un approccio per risolvere questo tipo di debito tecnico

   L'esperto consiglia di documentare attentamente tali casi per ritornare su di essi e correggerli prima che questo debito tecnico venga perso, diventando parte integrante della struttura del progetto.

2. Accidentale o derivante da un'architettura di progetto obsoleta Debito tecnico.

   Inoltre, il debito tecnico spesso si manifesta nel tempo, a causa di errori e carenze nella fase di creazione dell'architettura del progetto. Man mano che i sistemi si evolvono e i requisiti software cambiano, gli errori di progettazione diventano più evidenti e l’aggiunta di nuove funzionalità richiede più tempo e impegno. La qualità dell'architettura del progetto iniziale gioca un ruolo importante qui: dovrebbe essere semplice e funzionale, quindi sarà più facile adattarsi ai cambiamenti.

   Un approccio per risolvere questo tipo di debito tecnico

   Per evitare che questo tipo di debito tecnico si accumuli e non superi i livelli critici, Dag Llodden consiglia di eseguire regolarmente il refactoring, circa una volta ogni due anni, durante i periodi in cui il sistema è in uno stato stabile. I team leader e i product manager devono dedicare tempo per "pagare" questo tipo di debito tecnico che deriva dall'architettura e dai requisiti frequentemente mutevoli del progetto.

3. Debito tecnico che si manifesta nel tempo.

   L’esperto definisce questo debito tecnico “a putrefazione”. Si accumula nel tempo man mano che un componente o un sistema diventa gradualmente più complesso a causa delle numerose modifiche aggiunte costantemente. La situazione spesso peggiora se persone diverse lavorano sul sistema in fasi diverse e non comprendono appieno l'architettura originale.

   Un approccio per risolvere questo tipo di debito tecnico

   Questo è l'unico dei tre tipi di debito tecnico che dovresti cercare di evitare costantemente attraverso un regolare refactoring, dice l'esperto. Idealmente, un team di sviluppo dovrebbe prendersi il tempo necessario per comprendere a fondo l'architettura del sistema su cui sta lavorando, anche se è stato originariamente creato da altre persone. Comprendere il sistema ti consentirà di migliorare e correggere gradualmente il codice errato senza portare il progetto allo stadio di “marcio”.

Soluzioni tecniche per la gestione del debito

Esistono molte opzioni per gestire in modo efficace il debito tecnico, ma tutti gli esperti concordano sulla necessità di farlo, poiché il debito tecnico è parte integrante di quasi ogni sviluppo e le aziende che lo ignorano invariabilmente affrontano problemi nelle fasi successive. Ecco alcune soluzioni e approcci efficaci per la gestione del debito tecnico per un team di sviluppo.

1. Assegna una percentuale fissa del tuo tempo di lavoro al lavoro sul debito tecnico.

   Il problema del debito tecnico è che non c'è mai tempo per lavorare sulla sua eliminazione (perché ci sono sempre compiti con priorità più alta) a meno che non lo si faccia intenzionalmente. Pertanto, una buona soluzione sarebbe quella di destinare a questi scopi una certa percentuale fissa dell'orario di lavoro, circa il 20-25%.

   Questo può essere fatto in diversi modi.

2. Lavoro sul debito tecnico 1 giorno a settimana

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

Infine, vorrei sottolineare ancora una volta che è impossibile fare a meno dei debiti tecnici nello sviluppo del software, perché sono parte integrante dello sviluppo in quanto tale. Tuttavia, nonostante la sua natura tecnica, il TD è ancora un problema causato dal fattore umano in fase di sviluppo. E anche se non potrai farne completamente a meno, l’importo del debito tecnico può essere ridotto il più possibile se scrivi un codice “pulito” e ti avvicini al processo di sviluppo nel modo più responsabile e professionale possibile. Questo è ciò che auguriamo a tutti!