Le metriche del codice per quelli della NASA…

Ieri stavo leggendo questo articolo datato 1997 sulle metriche, pubblicato sul sito di un centro della NASA (Software Assurance Technology Center, http://satc.gsfc.nasa.gov/), che tra l’altro ha una sezione dedicata proprio alle metriche nel software (http://satc.gsfc.nasa.gov/metrics/index.html e http://satc.gsfc.nasa.gov/metrics/codemetrics/index.html).

Vabbe’, in questo articolo si presentano diversi tipi di metriche, sia tradizionali che OO.
Quando parla del numero ciclomatico dice: “In general, the cyclomatic complexity for a method should be below ten, indicating decisions are deferred through message passing.

Un altra metrica tradizionale e’ poi la seguente:
METRIC 3: Comment Percentage
The line counts done to compute the Size metric can be expanded to include a count of the number of comments, both on-line (with code) and stand-alone. The comment percentage is calculated by the total number of comments divided by the total lines of code less the number of blank lines. The SATC has found a comment percentage of about 30% is most effective. Since comments assist developers and maintainers, this metric is used to evaluate the attributes of Understandability, Reusability, and Maintainability.

Quanti progetti legacy per quelli della NASA avrebbe delle ottime metriche? :-)

E comunque voi sapete come mai anche il piu’ recente studio sulle metriche OO non arriva al 2000?!

Cercando su google ho trovato articoli vecchi, nessun nuovo studio, niente di niente!
Come mai?

Advertisements

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?

Commenti al post “Don’t Over-Use Mock Objects” di K.Ray

Tempo fa Giuliano aveva segnalato questo post di K.Ray: Don’t Over-Use Mock Objects

Mi sembra che le tesi dell’articolo siano un po’ forti (“Avoid them. Mocks make your tests more fragile and more tightly-coupled. And at the same time, they reduce the integration-test aspects of TDD. They make your tests larger and more complicated and less readable.”). Certo, se usati male possono dare problemi di fragilita’ eccessiva del test e di leggibilita’ (a meno che non si usi un po’ di literate programming con jMock), e soprattutto se non si usano per riflettere su eventuali debolezze del proprio codice (a questo riguardo il blog su www.mockobjects.com fa spesso illuminanti esempi di codice che usa scorrettamente i mock).

L’obiezione che i mock ridurrebbero la robustezza dei test e’ debole (“If you change an object’s API, a mock object’s API may not change, making your tests out-of-date with respect to your non-test code”), perche’ con EasyMock si usano le API ‘vere’, pertanto non esite la possibilita’ di avere dei metodi ‘out of date’ (non so come funzioni invece jMock).

L’unica osservazione secondo me con un certo fondamento e’ la critica al modo di procedere degli interaction-based testers (“In TDD, you normally write a test, write some code in a target class/method that passes the test. The third step is refactoring. … Test-Driving with Mocks inverts that order: you create your target class and a mock class up-front, and plan on how they interact, instead of evolving that interaction in TDD’s refactoring steps. You pre-judge the class design rather than evolve it.”). Anche a me suona innaturale di norma procedere come gli interaction-based testers, ma penso anche che ci siano casi in cui questa ‘esplorazione’ delle interazioni e’ utile.
Suonera’ un po’ eccessivo, ma qualcuno diceva che la programmazione dei mock in un test e’ un po’ come un sequence diagram sotto forma di codice! :-)

Siamo invece d’accordo che i mock sono utili per rendere piu’ indipendenti i test (“Mocks are tool for decoupling, and I do sometimes use them. I limit my use of Mocks to those situations where the real object will not reliably do what I want. Examples: simulating errors in writing a file; simulating connections with a remote server; simulating errors from remote server.”).