SOA (Service Oriented Architecture), Web As Platform, Data, Java and Open Source
Il debito tecnico è una metafora coniata da Ward Cunningham nel 1992 in un report per OOPSLA:
Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product.
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.
Che poi spiega meglio in un video nel 2009:
if you develop a program for a long period of time by only adding features and never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer.
I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.
if you want to be able to go into debt that way by developing software that you don’t completely understand, you are wise to make that software reflect your understanding as best as you can, so that when it does come time to refactor, it’s clear what you were thinking when you wrote it, making it easier to refactor it into what your current thinking is now.
the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem.
Il debito a cui si riferisce Cunningham è quello inevitabile, che si contrae anche con il software di ottima fattura, perché sviluppato secondo il livello di comprensione che si ha in quel momento. Questo è il tipo di debito che Martin Fowler, nell’articolo TechnicalDebtQuadrant, definisce “prudente e involontario”.
Lo stesso articolo definisce altri tre tipi di debito tecnico: “prudente e intensionale”, “temerario e intensionale”, “temerario e involontario”. E’ quanto schematizza l’immagine che segue.
La combinazione “prudente e intensionale” è piuttosto interessante: si decide di indebitarsi per avere del tempo in cambio. Deve essere una decisione strategica, ragionata con estrema cautela. Si accetta il rischio per sperimentare nuove funzionalità, ricevere feedback il prima possibile, consegnare alla data stabilita. E’ un compromesso, per cui si deve rinunciare a qualcosa: documentazione, implementazione dei test, rispetto di standard, ecc.
Il debito contratto deve essere ripagato in fretta: il business va informato della decisione e va attuato un piano di recupero. Probabilmente ci si può permettere di non ripagarlo solo se è relativo ad un software al termine del ciclo di vita.
Lo sforzo da sostenere per ripagare il debito, come spiegato da Cunningham, è proporzionale alla qualità di quanto si è prodotto contraendolo.
La necessità di idempotenza delle operazioni di compensazione e di conferma nel protocollo Try-Cancel/Confirm rende naturale la sua applicazione ad un’architettura in stile REST; ciò è quanto mostra la presentazione “Atomic Transactions for the REST of us“.
Come si vede dalla prima slide il Confirm e il Cancel corrispondono a operazioni idempotenti, per cui è possibile eseguirle quante volte si ritiene necessario – comunque entro il time-out.
La seconda slide mostra un possibile scenario.
Mi chiamo Andrea Gumina. Sono laureato in Scienze dell'Informazione e lavoro per un'azienda di consulenza IT. Da qualche anno mi occupo di integrazione di sistemi, di SOA (Service Oriented Architecture) da poco meno di cinque.
