Cos'è il debito tecnologico?

I debiti tecnici sono noti punti di implementazione ingegneristica che uno potrebbe aver scelto consapevolmente di non implementare in questo momento. I debiti tecnologici sono comuni da prendere, ma devono essere ponderati con giudizio. Presenteremo alcune linee guida su quando/come valutarle.

Idealmente, qualsiasi parte di codice, durante la sua prima implementazione, dovrebbe gestire tutti i casi noti. Tuttavia, possono esserci dei bloccanti:

1. In alcuni casi, si spera non comuni, la funzionalità del prodotto o la logica ingegneristica potrebbero non essere chiare. Ciò potrebbe anche essere una scala poco chiara o requisiti di traffico, che comportano il rischio di una preparazione insufficiente o eccessiva per il traffico e la scala.
2. Anche se l'implementazione è chiara per i casi d'uso non comuni, l'implementazione può essere complessa o richiedere molto tempo.

Tutti idealmente vogliamo ridurre al minimo i debiti tecnologici, ma ci sono momenti in cui ha senso prenderli.

La necessità di andare avanti

Anche se non avere tutti i dettagli o la piena implementazione può essere compromettente, spesso si deve andare avanti per una combinazione dei seguenti motivi:

1. Spesso si deve costruire o implementare qualcosa per rispondere a ulteriori domande, sfruttando il feedback parziale dell'utilizzo o del cliente. Il dithering può portare a ritardi che sono costosi ed è prudente rischiare un'implementazione non perfetta piuttosto che nessuna.
2. La specifica mancanza di chiarezza può essere relativamente insignificante nello schema più ampio della funzionalità da creare, può essere aggiunta o corretta facilmente e la mancata implementazione della funzionalità può essere più costosa.

Qualità

Quando prendiamo un debito tecnologico, abbiamo consapevolmente deciso di scambiare un'implementazione forse più corretta con un'implementazione parziale. Un buon debito tecnologico però:

1. Quando il debito tecnologico viene affrontato, provoca un minor tasso di abbandono del codice per il codice dell'implementazione attualmente scelta e
2. Porta a un grazioso fallimento di alcune parti non comuni della funzionalità. Al contrario, se risolto, si tratta di un miglioramento incrementale della funzionalità.

Bisogna solo prendere i buoni debiti tecnologici che soddisfano le qualità di cui sopra. Le seguenti domande ci aiutano a valutare.

Costo

Alcune domande da porsi quando si valuta il costo dell'assunzione del debito tecnologico o del caso mancato:

1. Dov'è la funzionalità mancante, ad esempio nella visualizzazione/presentazione dei dati o nella generazione dei dati? Più specificamente, la mancata funzionalità porta a dati permanentemente errati?
2. Qual è l'aspetto negativo dell'esperienza utente? È un caso d'uso comune in cui è probabile che gli utenti inciampino e non siano contenti o un caso insolito ai margini della nostra proposta di valore fondamentale?
3. Siamo sicuri dei dettagli della progettazione e dell'implementazione delle funzionalità mancanti o saltate? O preferiremmo avere un feedback sull'implementazione parziale per definirlo?

Prendiamo debiti tecnologici per alcuni vantaggi:

1. Rilascio più rapido, che potrebbe portare a un aumento delle vendite o alla soddisfazione del cliente.
2. Potenziale per ottenere dati o feedback sull'adozione, portando forse a una progettazione migliore della funzionalità mancante. Per alcune funzionalità poco chiare, potrebbe essere necessario.
3. Il costo opportunità dello sforzo ingegneristico risparmiato a breve termine.

Seguire i principi fondamentali di base di un design robusto riduce al minimo la rielaborazione che comporta affrontare il debito tecnologico.

Modularità

Assicurati che i servizi e gli oggetti siano ben pensati con interfacce ben definite. La modularità consente di localizzare le modifiche senza ridurre al minimo l'ingombro della rielaborazione del codice.

Prova a pensare oltre l'immediato, ad es

1. Se al momento disponiamo di un'implementazione della funzionalità, ma in seguito potremmo forse inserire l'implementazione come sottoclasse di un'interfaccia. Ciò facilita l'aggiunta di ulteriori implementazioni in un secondo momento.
2. Se un'entità ha attualmente un possibile valore per il campo ma potrebbe in seguito averne di più, rendilo un enum.

Schema pulito

Un buon schema di database e un modello ORM che modella da vicino il caso d'uso della vita reale di solito è robusto per ulteriori modifiche.

Buone pratiche di codifica

1. Mantieni i valori che possono essere modificati ASCIUTTI e non in profondità nel codice. Possono essere variabili di configurazione di input di runtime o costanti di codice. Questa deve essere una decisione consapevole.
2. Alcune funzionalità richiedono la possibilità di iterare rapidamente o personalizzare per cliente. Usa strumenti a basso / nessun codice, sono facili da iterare, anche un po 'da un non ingegnere. E c'è meno codice e quindi meno abbandono.
3. Si applicano le pratiche generali di codifica e progettazione sopra menzionate, ad esempio mantieni il codice ASCIUTTO (è facile modificare il codice in un punto), mantienilo semplice (quindi più facile da capire per cambiare), ecc.
4. Alcune modifiche saranno additive, letteralmente basate sullo status quo, ad esempio l'aggiunta di set di repliche a un server di database mongo a nodo singolo esistente o lo sharding a un server di database mongo. Se questi sono costosi da implementare, la necessità di tali miglioramenti può essere spostata più in basso nella sequenza temporale fino a quando non sarà necessario senza alcuno sforzo aggiuntivo.

Non gestire tutti i casi non è un motivo sufficiente per controllare il codice. Invece, di seguito è riportato un modo per andare avanti:

1. Continua a impegnare il codice nel tuo ramo con abbondanti commenti TODO sulla funzionalità in sospeso o sugli elementi di chiarimento.
2. Idealmente, risolvi tutti gli TODO prima di aumentare la richiesta pull.
3. Qualsiasi problema irrisolto diventa un debito tecnico: assicurati che il revisore del codice e il responsabile tecnico/responsabile pertinente siano taggati/informazioni, debito tecnico creato da Jira e ID Jira menzionato nel commento. Si spera che la revisione delle PR dovrebbe riconfermare che il debito tecnologico è accettabile.
4. Assicurati che il codice gestisca con garbo anche i casi non gestiti, ad esempio il front-end riceve una risposta API appropriata per mostrare l'errore dell'input API non ancora gestito piuttosto che l'arresto anomalo del back-end.
5. Tieni a mente una sequenza temporale per il debito tecnologico Jira, possibilmente mantenendola nello sprint successivo in modo che venga visualizzata nella chiamata di pianificazione dello sprint per la revisione iniziale.