Verifica automaticamente la qualità del codice tramite metriche?

È assolutamente impossibile controllare automaticamente la qualità del codice, puoi solo controllare la qualità minima del codice.

Anche i programmatori "esperti" hanno difficoltà a formalizzare ciò che costituisce effettivamente la qualità del codice. E anche tra i "più abili", c'è un'alta divergenza nell'opinione su ciò che è buono o cattivo.

Ci sono alcune regole ovvie che non dovrebbero essere infranti. Mille linee in un metodo sono decisamente troppe. C'è anche un migliaio di membri in una classe. Nessuno potrebbe discutere su questo. La maggior parte delle persone sceglierebbe per numeri più piccoli. Personalmente, raramente ho un file con più di 200 LOC, ma dipende in gran parte dal gusto personale, dall'abitudine e anche dal linguaggio di programmazione usato.

Il fatto è che gli strumenti di analisi automatica del codice possono utilizzare solo criteri piuttosto semplici. Pertanto, non diversamente dai test , non possono mai essere utilizzati per accertare la qualità del codice, ma solo per determinarne l'orribile mancanza. Se esiste un modo assoluto per definire la qualità del codice, direi che significa un rapporto ragionevole di complessità tra una soluzione e il problema che risolve.

Tuttavia non ti interessa la qualità del codice in quanto tale e non cerchi il suo valore assoluto - beh, personalmente puoi (spero che tu lo faccia), ma le persone che ti pagano in genere non gli interessano. Quello che ti interessa davvero è la manutenibilità e idealmente un fattore di basso costo.
E questo è qualcosa di relativamente soggettivo, dipende molto dalle persone della tua squadra. Devono essere in grado di guardare un pezzo di codice e capire cosa sta facendo. E questo alla fine può essere raggiunto solo attraverso la revisione del codice.

Quindi, mentre è possibile implementare mezzi automatizzati per scoprire ovviamente un codice errato, non è possibile implementare tali mezzi per assicurare veramente un buon codice. Solo le revisioni del codice possono farlo (o almeno drasticamente aiutano a raggiungere questo obiettivo) e sicuramente ti proteggono dal codice che è ovviamente negativo.
Quindi dipende molto dalla tua squadra (dimensione, continuità, ecc.), Indipendentemente dal fatto che un controllo automatico abbia senso. Potrebbe anche risparmiare tempo per fare cose più importanti nelle recensioni. O potrebbe solo far incazzare la gente a non finire. A lungo termine dovresti trovare la disciplina per non commettere codice super-ovviamente-cattivo in primo luogo. Non è davvero così difficile e paga davvero.

Penso che sia certamente possibile.

Tuttavia: non dovrebbe mai rompere la build.

Non conosco software che si integri con CI al di fuori del gate per questo tipo di analisi statica (come fa FxCop), tuttavia, penso che possano / debbano essere sollevati come avvertenze che dovrebbero contrassegnare quelle aree per recensioni di codice. Dopo la revisione, tali avvisi possono essere soppressi se la revisione del codice appone il codice. Simile a come FxCop e StyleCop hanno soppressioni nelle soppressioni source / globals.

In sintesi: queste metriche sono migliori come gli odori di codice, non gli errori di codice.

No

Secondo me è molto più difficile di quanto valga. Se si dispone di programmatori mediocri, essi rifletteranno servilmente il loro codice per soddisfare il poliziotto di stile, rendendo il codice ancora peggiore. Se limiti il numero di membri della classe, otterrai qualcosa di simile a questo:

class BunchOfStuff {
  public class Bunch1 { // properties with names from A-M
     Integer a { get; set; }
     Double b { get; set; }
     ...
  }
  public class Bunch2 { // N-Z
     ... 
  }

  Bunch1 bunch1 { get; }
  Bunch2 bunch2 { get; }
  ...
}

L'ho visto. In risposta a un controllo automatico per i "numeri magici", almeno uno sviluppatore ha risposto in questo modo:

private static final int SEVENTEEN = 17;
...
Something[] things = new Something[SEVENTEEN];

Se vuoi codice mantenibile, non c'è un sostituto per il buon giudizio e un secondo paio di occhi.

Uso l'analisi statica e l'amp; strumenti di linting come parte del mio CI e processo di compilazione, e trovo sia utile che utile. Ci sono degli svantaggi, ma la sicurezza aggiunta che ottieni nella qualità del codice lo rende utile, IMHO.

Ci sono state molte occasioni in cui l'analisi statica ha rifiutato funzioni mie che altrimenti avrei considerato abbastanza ragionevole; ad esempio troppe variabili o troppi argomenti di input, eccessiva complessità di McCabe, ecc ... Tuttavia, sono sempre stato in grado di prendere una visione filosofica e di rifattorizzare il codice in conformità.

Come risultato di questo approccio, mi sento molto più a mio agio con il mio codice base e posso muovermi molto più velocemente quando ho bisogno di apportare modifiche.

I benefici principali sono psicologici e sono significativi e significativi.

(Per me, la chiave per farlo funzionare bene è usare gli strumenti di analisi statica fin dall'inizio, poiché il refactoring del codice legacy per soddisfare gli standard di qualità del codice è un fastidio sul retro, mentre lo sviluppo continuo di il codice conforme è molto più semplice).

Solo le metriche non sono sufficienti, ma possono fornire ottime informazioni sul codice. Proprio come ogni metrica, devono essere interpretati per avere un significato.

Considera un tavolo lungo 2 metri. È troppo? Non abbastanza ? In realtà, dipende da cosa vuoi fare con la tabella.

Inoltre, ci si aspetta che la maggior parte del codice abbia una bassa complessità ciclomatica, ma si prevede che gli algoritmi abbiano uno più grande del normale codice. Quindi, a seconda del codice, ciò che è buono o cattivo può cambiare.

Come metrica, dovresti dare un'occhiata a:

• NPATH (misura la complessità logica di un pezzo di codice).
• CRAP (una metrica che combina la complessità ciclomatica con la copertura del codice per dirti quanto è rischioso cambiare un dato pezzo di codice).
• Accoppiamento astratto dei dati, ingresso e uscita della ventola (per avere un'idea della qualità dell'isolamento all'interno di un'applicazione).

Alcuni problemi non verranno rivelati dalle metriche che conosco. Per esempio, l'accoppiamento temporale. La metrica non può essere un sostituto per la revisione del codice o qualsiasi processo di qualità che hai in azienda. Questa è, tuttavia, una grande aggiunta e può aiutare nel compito.

A proposito, Sonar fornisce ciò che è necessario per automatizzare la misurazione delle metriche del codice e creare report. Scoprilo: link