Piu’ volte su questo blog ho parlato di quanto sia importante la qualità per abbattere i costi totali.

Con questo post voglio riflettere piu’ nel dettaglio per comprendere quando una soluzione comoda e magari poco elegante possa avere senso. Inoltre quando paga rifattorizzare una soluzione dal forte grado di accoppiamento tra le componenti?

Di seguito un piccolo sunto del paragrafo “When to refactor” di “Refactoring, improving the design of existing code“:

• Regola dei tre strikes: “la prima volta implemento la piu’ semplice, la seconda volta, consapevole della duplicazione, duplico, la terza volta che faccio qualcosa di simile, rifattorizzo”
• Quando si fixa un bug: codice piu’ chiaro e/o si migliora la testabilità
• Quando una nuova funzionalità deve innestarsi in codice poco chiaro: migliorare la comprensibilità per diminuire il rischio di interventi non corretti
• Quando rende piu’ veloce implementare una nuova funzionalità: migliorare la malleabilità

Alla base del refactoring vi è l’idea di minimizzare il costo di cambiamenti futuri non con una previsione degli stessi, ma creando un design che per la sua semplicità sia in grado di essere modificato e reso pronto a qualsiasi cambiamento con poco sforzo. L’effort di tali modifiche (aka mosse di Refactoring) rimane relativamente basso se e solo se il design è mantenuto ragionevolmente semplice. La pratica del TDD a questo fine è un arma molto potente.

Sappiamo tuttavia che anche con un processo scope-oriented e con un team Agile, molto spesso ci si trova ad avere applicazioni o zone dell’applicazione con del debito tecnico. In questi casi cercare di scontare quel debito di design seguendo unicamente le linee guida sopra elencate per la mia esperienza non è efficace. Spesso in presenza di un forte debito tecnico ereditato dal passato, i refactoring sarebbero molto, troppo estesi. Dire semplicemente facciamoli a piccoli passi non mi aiuta molto: servono delle euristiche che tengano conto del contesto e dei particolari vincoli di risorse.

Alcuni dei dubbi che sorgono spesso quando devo scrivere una funzionalità e mi imbatto di fronte a codice poco chiaro, troppo complesso o pieno di smell, sono:

1. Ha senso per questa funzionalità, fare refactoring?
2. Fino a che punto ha senso addebitare a questa storia il costo aggiuntivo (pagare il debito) derivante dal refactoring?
3. In altri termini: ammesso che in questa particolare situazione sia piu’ veloce ignorare il disordine non rifattorizzando, ha senso mettere ordine nel design, o per questa funzionalità in realtà sarebbe piu’ efficace non farlo?

Sono domande che spesso mi hanno portato a frustrazione per mancanza di linee guida che realmente mi dessero un aiuto concreto per cercare una risposta. Sto parlando delle situazioni in cui fare refactoring aggiunge un costo alla storia rispetto all’aggiungere la funzionalità senza farlo. In caso contrario è chiaro che la scelta non si pone neanche.

Dal momento che ragionamenti puramente tecnici non mi hanno dato una mano per prendere queste decisioni, ho provato a guardare piu’ in alto, a cercare delle linee guida illuminato dagli obiettivi di business della particolare storia sulla quale si pongono quelle scelte. Ancora una volta mi sono sentito piu’ libero come programmatore ponendomi domande a livello di business.
Ad oggi i ragionamenti che faccio per farmi guidare sono guidati da un’analisi costi/benefici:

• Su questa storia, con un valore X e stimata di un costo Y, è ancora ragionevole il rapporto costi/benefici aumentandone il costo? Esempio: una storia mi dà Valore 10, e costa 5 senza refactoring. Con il refactoring aggiuntivo, il costo salirebbe a 7. Ha ancora senso per il business sviluppare quella storia? Se no, è possibile fare solo una parte del refactoring?

• Analisi costi/benefici a “medio/lungo termine“: riguardo a questo vi sono due aspetti:
1. la mantenibilità (=complessità, rischio di errori, comprensibilità) del SW che implementa la storia, alla luce del refactoring/non refactoring, quale sarà?
2. quali probabilità vi sono di avere estensioni future in qualche modo legate alla storia? Confrontare costi dell’investimento aggiuntivo rispetto all’ipotetico valore guadagnato in futuro.

Il secondo punto implica tra le altre cose, una consapevolezza del design che non è scontata. Implica da un punto di vista tecnico essere in grado di comprendere quali sono i punti di estendibilità lasciati dal codice, quali gli assi di cambiamento ai quali le varie classi rispondono, sapere identificare gli smell ed i debiti del codice, quali parti del codice andrebbero cambiate per supportare una nuova funzionalità.

Senza questi skills da parte dei programmatori e senza un management fondamentalmente orientato alla qualità diventa molto rischioso prendere queste decisioni. Vedere la qualità come l’unica variabile del processo su cui sia possible tagliare è sempre dietro l’angolo. Inutile ripetere che questo approccio non paga.

E’ importante saper valutare quali sono i requisiti e le regole di business a piu’ alta volatilità, isolarli dal resto del sistema ed investirvi le giuste risorse. Una buona strategia puo’ essere di guardare nella storia passata, evincendo la frequenza di cambiamento, la volatilità del sistema sotto osservazione. Ad esempio per una zona del sistema per cui sappiamo che il cliente non chiede modifiche da svariati mesi, avrà senso investire un costo aggiuntivo di refactoring minore rispetto ad una zona con alta probabilità di cambiamento, o su un progetto nuovo. Tutto questo puo’ essere fatto solo a stretto contatto con il product manager e con il business, analizzando Vision del prodotto e obiettivi di business.

Anche nel caso frequente in cui non si riesca ad arrivare a dei numeri, il solo fatto di fare ragionamenti di questo tipo permette di prendere una decisione in modo piu’ consapevole. Ad ogni modo nel dubbio, preferire la scelta che si muove verso la soluzione pulita: gli interessi da pagare per un Debito Tecnico possono diventare molto alti.

Concludo con una piccola esperienza personale. Un programma che importa dei nuovi clienti nel nostro sistema presentava dei costi fissi incidentali dovuti all’intervento umano a causa di errori di vario tipo nei dati da importare. Le scadenze imposte dal Boss per il particolare import dei clienti e l’impatto di un ritardo, non permettevano una modifica “pulita” al fine di gestire tali errori nei dati in modo automatico. Si è tuttavia deciso pragmaticamente di effettuare un piccolo passo verso l’aumento del Ritorno, sacrificando la mantenibilità (abbiamo duplicato) del codice, a favore del ritorno derivante dall’alta frequenza con la quale quell’importer veniva eseguito. Abbiamo paragonato il costo dovuto alla necessità dell’intervento umano, valutato sulla frequenza dell’esecuzione dello stesso, rispetto al costo della modifica per eliminarlo e al costo della mantenibilità, arrivando ad un numero che rendeva piu’ evidente la scelta.

Ragionare in questi termini aiuta molto i programmatori, fornire questi dati al Business in modo da metterlo in grado di prendere una scelta informata rende tutto il processo molto piu’ “smooth”.

Il valore guadagnato con la modifica all’Importer puo’ essere letto inoltre come un Credito spendibile anche solo in parte per ripulire l’Importer alla sviluppo della prossima funzionalità che lo interessa.
I vantaggi derivanti dall’aver abbattuto dei costi fissi per un’attività ad alta frequenza in questo caso superavano i costi aggiuntivi che potenzialmente la mantenibilità della modifica stessa comporterà. In questo caso quindi un’azione di Refactoring aveva poco senso, perchè avrebbe reso insostenibile la modifica all’importer.

Alcuni link sull’importante concetto di Debito tecnico:

• ComplexityAsDebt
• TechnicalDebt
• DesignDebtDynamics
• Piccola retrospettivo del primo progetto TDD
• Five-Design-Skills