L’importanza di un basso debito tecnologico nello sviluppo di software.
Uno spettro aleggia sulle notti insonni, sulle bolletta della luce e sulla voglia di vivere di un team di sviluppo. Non è il project manager che deve marginare anche sulle virgole, ma (rullo di tamburi e apertura del sipario sul protagonista): il debito tecnologico. Niente a che vedere con la ludopatia, men che meno con Matrix e l’agente Smith.
Quindi di cosa parliamo?
Il debito tecnologico è un concetto che associa lo sviluppo del software al debito finanziario, ed è generalmente la somma del debito software, di architettura e dell’infrastruttura. Aramaico antico? La stele di Rosetta ha creato meno problemi di codifica? Affrontiamo la questione passo passo, tenendoci stretti per mano.
Nel momento in cui un team decide di sviluppare un sistema preferendo la rapidità alla correttezza del codice, sa di trovarsi in una situazione scomoda. Dettata, chiaramente, da necessità e dal project manager di cui sopra. Nella scelta per la strada più veloce, verrà accumulato del lavoro nel futuro per manutenere o per aggiornare la tecnologia scelta ed utilizzata. Non sempre la scelta di sviluppare un software prediligendo la rapidità è dettata da una mancanza tecnica del team di sviluppo, anzi, spesso, è dovuta a tempistiche strette, da un basso budget o più semplicemente da esigenze di mercato.
Come tutti i debiti anche quello tecnologico accumula “interessi”, ogni intervento “quick and dirty” che ci permette oggi di far funzionare l’esistente accumula un debito che prima o poi qualcuno dovrà riscuotere. Più cose verranno gestite “alla giornata” e più gli interessi che dovremo pagare saranno alti.
Come ben sanno gli addetti ai lavori l’aggiornamento di un’infrastruttura o di un framework utilizzato per lo sviluppo di un software è spesso un lavoro lungo, tedioso e non privo di ostacoli ma che purtroppo, durante il ciclo di vita di un applicativo, prima o poi si rende necessario.
Cosa può fare uno sviluppatore per poter tener basso il debito tecnologico?
Può scegliere un paradigma di programmazione che gli consenta di aggiornare o cambiare framework senza dover reingegnerizzare l’intero applicativo!
Architettura esagonale di Alistair Cockburn
Alistair Cockburn introduce il concetto di architettura esagonale, nota anche come pattern “Port and Adapter”.
L’idea di Alistair è quella di superare la tipica rappresentazioni per livelli (layered model) per adottare una rappresentazione concentrica tipicamente simboleggiato da una forma esagonale che pone al centro il core application dove risiedono gli oggetti di dominio che rappresentano nel loro insieme la logica e le regole di business dell’applicativo stesso. All’interno del cosiddetto “core application” si parla il linguaggio del dominio e non ci sono riferimenti alle tecnologie utilizzate (framework) che sono invece all’esterno dell’esagono.
