Affinare La Metrica
La recente discussione in seno al team XPlayers di Quinary sulle nostre metriche e su come affinarle mi ha fatto riflettere un po’ e volevo condividere con voi questi pensieri, ovvero una proposta di cambiamento della metrica (da sottoporre a prova sul campo, si intende).
Il nostro magic number, dopo varie discussioni su quali fattori includere, e’ stato definito all’inizio in questo semplice modo
Magic Number = NCSS / (LCOM * CCN)
dove le premesse erano che (ditemi se sbaglio):
se NCSS cresce e’ un bene (maggiore produttivita’?)
se LCOM scende e’ un bene (maggiore coesione)
se CCN (McCabe) scende e’ un bene (minore complessita’ “di flusso”)
Io penso che in questa formula NCSS abbia un peso troppo forte, e questo favorisce oscillazioni come quelle che abbiamo osservato nelle scorse settimane (vedi thread su “Metriche di oggi”).
Ora, non so per certo se queste oscillazioni siano giuste o meno, e capisco anche che, cosi’ come esiste il ‘debito di refactoring’ quando si scrive molto codice ma lo si rifattorizza poco, possa esistere una sorta di ‘debito di produttivita diretta’ quando si rifattorizza molto (e quindi si produce un delta di NCSS piccolo o addirittura negativo).
Pero’ penso che sia giusto far entrare nella formula un fattore che premia il codice rifattorizzato, e pertanto propongo di provare la seguente formula
Magic Number = NCSS / (LCOM * CCN * lunghezza media dei metodi)
dove lunghezza media dei metodi = NCSS / #metodi
il che significherebbe, semplificando i fattori
Magic Number = #metodi / (LCOM * CCN)
questa variazione permette secondo me (ma vorrei provarla per avere una qualche certezza) di premiare certamente la produzione di codice (come accadeva per l’NCSS), ma di codice rifattorizzato (che poi sia ben rifattorizzato questo non saprei come misurarlo).
In altre parole se scrivo tanto codice nuovo, ma lo metto in pochi metodi grossi ho un incremento minore di quanto non avrei se lo stesso codice fosse messo in metodi piu’ brevi e concisi.
Che ne dite?