Valori usuali su metriche codice (C#, Visual Studio) per progetti di produzione

Question

Qui ci sono alcune domande sulle metriche del codice, in particolare this one sui valori degli obiettivi. Quello che sto cercando è ciò che è "normale" nei progetti di produzione di vita reale. Forse sono solo io, ma nessun progetto su cui io abbia mai messo piede ha in mente queste cose, quindi quando eseguo ReSharper Code Issues o Visual Studio Code Metrics sembra che io sia il primo - quindi i valori mi sorprendono sempre.

Esempi dal mio incarico di SharePoint corrente:

Maintainability | Cyclomatic cmplx. | Inher. depth | Class coupl. | LOC 
67    | 6,712    | 7   | 569   | 21,649 
68    | 3,192    | 7   | 442   | 11,873 

Aggiornamento: Quindi la domanda è, quali valori si fa di solito si vede "in the wild"? Valori ottimali e migliori pratiche a parte, quali valori si incontrano normalmente?

Answer 1

Suppongo che questi valori dichiarati siano a livello di assieme. In tal caso, Complessità ciclica e Le righe di codice sono più utili a livello di metodo. La profondità di successione deve essere considerata principalmente a livello di classe. L'accoppiamento di classe fornisce un feedback più utile quando si guarda prima al livello del metodo e poi a livello di classe.

In aggiunta alle linee guida che forniscono nel stack overflow link te incluso, codice completo 2nd Edition ha questo da dire sul metodo complessità ciclomatica, pagina 458:

• 0-5 La routine è probabilmente bene.
• 6-10 Iniziare a pensare ai modi per semplificare la routine.
• 10+ Rompere parte della routine in un secondo routine e lo chiamano dalla prima routine

Nei progetti di "vita reale", ciò che è accettabile probabilmente dipenderà dal tipo di processo di sviluppo si è utilizzando. Se il team sta praticando TDD (test-driven-development) e si sforza di scrivere il codice SOLID, queste metriche dovrebbero essere vicino ai valori ottimali.

Se TAD (sviluppo in prova) o, ancor più, codice senza test di unità, si aspettano che tutte le metriche siano più elevate di quelle ottimali come la probabilità di avere più accoppiamento, metodi e classi più complessi e forse più l'eredità prolifica può essere elevata. Tuttavia, l'obiettivo dovrebbe essere quello di limitare i casi di avere metriche "cattive", indipendentemente da come è stato sviluppato il codice.

Answer 2

L'idea sbagliata di base sulle metriche del software è che sono utili quando inserite in un bel report.

maggior parte delle persone utilizza il seguente processo imperfetto:

• Raccogliere qualunque sia le metriche loro sostegno utensili
• Compilare un report
• confrontarla con i valori raccomandati
• iniziare a caccia di una domanda che il loro nuovo trovato risposta potrebbe indirizzo

Questo è sbagliato, indietro e controproducente su così tanti livelli non è nemmeno divertente.L'approccio corretto per ogni incontro metriche è prima capire il motivo per cui . Qual è la tua ragione per misurare? Con che hanno risposto si potrebbe capire che cosa misurare e dato che si conosce il motivo per cui e cosa si riesce a capire come per ottenere alcune informazioni che potrebbero guidare ulteriori indagini.

Ho visto una vasta gamma di valori per le metriche che hai elencato e per essere onesto in tutti i progetti o ambienti i confronti in realtà non hanno molto senso.

si può essere abbastanza certi che la stessa squadra produrrà roba che sembra la roba che hanno fatto in precedenza. Ma non hai bisogno di metriche per capirlo.

È possibile utilizzare le metriche per trovare "hot-spot" da esaminare, ma se si riscontrano problemi di qualità, i bug si raggruppano in moduli problematici e la ricerca di tali errori è in gran parte inutile.

Ora non fraintendetemi. Amo le metriche. Ho scritto più script & strumenti per estrarre la visualizzazione e fare tutti i tipi di cose di fantasia con loro, è tutto molto divertente & potrebbe anche essere stato utile, io non sono poi così sicuro di quello più tardi.