Übliche Werte für Code-Metriken (C#, Visual Studio) für Produktionsprojekte

Question

Hier sind einige Fragen zu Code-Metriken, insbesondere this one zu Zielwerten. Was ich aber suche, ist, was in realen Produktionsprojekten "üblich" ist. Vielleicht ist es nur ich, aber kein Projekt, das ich jemals umgesetzt habe, hat diese Dinge im Hinterkopf. Wenn ich also ReSharper Code Issues oder Visual Studio Code Metrics starte, scheint es, dass ich der Erste bin - also überraschen mich die Werte immer wieder.

Beispiele aus meiner aktuellen Sharepoint-Zuordnung:

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

Update: Die Frage ist also, welche Werte sehen Sie in der Regel "in the wild"? Optimale Werte und Best Practices beiseite, welche Werte sind normalerweise anzutreffen?

Answer 1

Ich nehme an, diese angegebenen Werte sind auf einer Assembly-Ebene. Wenn ja, Cyclomatic Complexity und Zeilen von Code sind auf der Methodenebene am hilfreichsten. Vererbung Tiefe sollte in erster Linie auf Klassenebene betrachtet werden. Klassenkopplung gibt nützlichere Rückmeldungen, wenn zuerst auf Methodenebene und dann auf Klassenebene gesucht wird.

Zusätzlich zu den Bereitstellung von Richtlinien in der stack overflow link Sie enthalten, Code Complete 2nd Edition hat folgendes zu sagen über Methode Zyklomatische Komplexität, Seite 458:

• 0-5 Die Routine ist wahrscheinlich in Ordnung.
• 6-10 Denken Sie darüber nach, wie Sie die Routine vereinfachen können.
• Teil der Routine in eine zweite Routine brechen 10+ und es von der ersten Routine

In „wirklichen Leben“ Projekte nennen, was akzeptabel ist wahrscheinlich von der Art des Entwicklungsprozesses abhängen Sie sind verwenden. Wenn das Team TDD (test-driven-development) ausübt und danach strebt, SOLID Code zu schreiben, sollten diese Metriken nahe den optimalen Werten liegen.

Wenn TAD (Test-nach-Entwicklung) oder, noch mehr, ohne Unit-Tests, dann erwarten Sie, dass alle Metriken höher als optimal als die Wahrscheinlichkeit von mehr Kopplung, komplexere Methoden und Klassen und vielleicht mehr fruchtbare Vererbung kann erhöht sein. Dennoch sollte das Ziel darin bestehen, die Fälle von "schlechten" Metriken zu begrenzen, unabhängig davon, wie der Code entwickelt wurde.

Answer 2

Das grundlegende Missverständnis über Software-Metriken ist, dass sie nützlich sind, wenn sie in einen hübschen Bericht eingefügt werden.

Die meisten Menschen verwenden den folgenden fehlerhaften Prozess:

• sammeln, was ihre Werkzeuge Unterstützung Metriken
• Kompilieren einen Bericht
• es vergleichen gegen empfohlenen Werte
• Start für eine Frage der Jagd, dass ihre neuen gefunden Antwort könnte Adresse

Das ist falsch, rückwärts und kontraproduktiv Auf so vielen Ebenen ist es nicht einmal lustig.Der richtige Ansatz für die Erfassung von Metriken ist zunächst herauszufinden, warum. Was ist dein Grund für das Messen? Damit beantwortet Sie herausfinden könnte, was zu messen und da wissen Sie warum und was Sie aus herausfinden kann, wie einige Informationen zu erhalten, die weitere Nachforschungen führen könnten.

Ich habe eine breite Palette von Werten für die Metriken gesehen, die Sie aufgelistet haben, und um ehrlich zu sein, über Projekte oder Umgebungen hinweg macht der Vergleich wirklich keinen Sinn.

Sie können ziemlich sicher sein, dass das gleiche Team Zeug produzieren wird, das wie die Sachen aussieht, die sie vorher gemacht haben. Aber Sie brauchen keine Metriken, um das herauszufinden.

Sie können die Metriken verwenden, um "hot-spots" zu finden, aber wenn Sie Qualitätsprobleme haben, werden sich Bugs in problematischen Modulen auflösen und es ist nutzlos, nach ihnen zu suchen.

Verstehen Sie mich nicht falsch. Ich liebe Metriken. Ich habe mehrere Skripte geschrieben & Werkzeuge zu extrahieren visualisieren und alle Arten von ausgefallenen Sachen mit ihnen zu tun, es ist alles gute Spaß & könnte sogar vorteilhaft gewesen sein, ich bin nicht so sicher, der später obwohl.