Calcola i costi di codice errato

Sto cercando argomenti per convincere il management a investire gli sforzi nel refactoring.

Registriamo il lavoro usando Jira e mettiamo in relazione ogni svn-commit con una chiamata jira.

La mia idea è di fare quanto segue:

• individua manualmente un'area di codice che è estremamente mal implementata, ma spesso usata: sia da User-POV che da Developer-POV (bugfixes)
• ottenere i svn-commit che contengono i problemi JIRA
• filtrare i problemi in base ad alcuni criteri (tipo di problema, versione, prio, ecc ...)
• calcolare il tempo / lo sforzo speso per questi bug
• stimare sforzi e rischi di refactoring
• presentare i numeri e chiedere sforzi per risolverli.

Cosa ne pensi di questo? Tale misurazione sarebbe utile e / o convincente? Quali sono i pro e i contro?

Ho scoperto che se è possibile fornire numeri validi, è più probabile che i manager agiscano. (Se riescono a comprendere la logica e il costo / beneficio.)

IMHO, per fare un caso convincente, avresti bisogno di quanto segue per mostrare quanto è brutto:

• numero di incidenti di supporto registrati per i problemi
• tempo impiegato in ore per mantenere / aiutare il cattivo codice / fare correzioni di supporto
• costo del tempo basato sulla tariffa oraria delle persone che effettuano la manutenzione / aiuti / supporto di banda
• un modo per dimostrare quanto siano cruciali questi elementi per l'azienda

E per fare il caso del refactoring, avrai bisogno di:

• tempo stimato per refactoring e attuare ciascuna delle prime 3 di queste cose cattive
• stima dei costi di implementazione (stesse tariffe orarie utilizzate sopra)

Con questi, è possibile risparmiare tempo se il refactoring richiede molto meno del tempo di supporto per 3 incidenti per ciascuno di quei 3 articoli principali. Si può sostenere che questo breve periodo di tempo trascorso lo farà

• essere inferiore a n più incidenti di supporto
• non ci saranno più questi incidenti per queste cose (ANCORA MEGLIO!)

Tuttavia, la parte più difficile di questa vendita risponderà alla seguente domanda, dal momento che molte persone non prevedono il budget nei tempi previsti per tutto il supporto che stai facendo:

Quanto ancora dovrò aspettare che il progetto Y attuale venga completato mentre passi il tempo a lavorare su questi problemi con X ????? (nonostante gli attuali tempi di supporto, che non possono essere previsti e programmati nei grafici di Gantt)

Ciò dipende molto da quanto bene comunichi con i responsabili delle decisioni e da come comprendono la situazione.

Sicuramente penso che valga la pena farlo, quindi hai la pratica di costruire il caso con le metriche e di risparmiare tempo, anche se non lo fanno. Sfortunatamente, non tutti sono facili da convincere, nonostante i dati. IN BOCCA AL LUPO!

Tieni presente che il refactoring introduce anche dei bug (che rileverai nei tuoi test, ma sono comunque bug e devono essere corretti). Non tirare Netscape per caso. Dipende dalla tua definizione personale di "refactoring". Per alcuni, questo significa "riscrivere tutto il codice" per altri significa "cambiare alcuni interni". Come dici di che tipo sei? Ponetevi la seguente domanda:

Sto cambiando l'interfaccia pubblica?

Se la risposta è sì, stai facendo una riprogettazione. Se la risposta è no, stai eseguendo il refactoring e probabilmente puoi semplicemente farlo nel corso delle tue attività quotidiane senza un'approvazione speciale. Questo è rilevante per la tua domanda perché una riprogettazione genererà molti più bug, mentre un refactoring è di solito più semplice da eseguire (poiché i tuoi test eserciteranno già l'interfaccia pubblica e non dovranno essere modificati).

È un caso difficile da risolvere, perché nessuno sa mai quanto X sarebbe costato con o senza il refactor fatto un anno fa. Nella mia esperienza i gestori pragmatici abbattono sempre questo genere di cose perché:

1. Nessun flusso di entrate dirette deriva dallo sforzo (costo finanziario, non fatturabile)
2. Il brutto codice di lavoro è ancora un codice di lavoro, rischi di creare problemi invece di risolverli (potenziale costo di qualità)
3. Altri progetti verranno ritardati durante il refactoring (costo del tempo)

A tutti questi numeri sono in ultima analisi, basate su supposizioni, nel tuo caso confrontando il valore si indovina che costerebbe non di refactoring rispetto a quello che si indovina che costerebbe a refactoring. Il meglio che puoi fare è dimostrare di avere una sorta di base numerica e fattuale per le ipotesi, e ne hai una abbastanza buona.

I pro sono che probabilmente sarà efficace nel convincerli a farti refactoring, e potrebbe andare bene e ridurre il numero di bug.

I contro sono che se la quantità di tempo impiegata a correggere i bug non diminuisce almeno quanto il tempo impiegato per il refactoring, probabilmente non ti sarà più permesso di refactoring e probabilmente verrai incolpato per il tempo "sprecato" .

I risparmi nel tempo di debug ottenuti riducendo la complessità dell'intero progetto o nel rendere più semplice l'aggiunta di funzionalità, potrebbero essere troppo difficili da misurare per aiutarti molto, ma potresti menzionare che esistono.