Quellcodemetriken zur Messung der Codestabilität?

In Anbetracht der Entwicklung von Software während eines Veröffentlichungszyklus (Implementierung, Testen, Fehlerbehebung, Veröffentlichung) dachte ich, dass man in der Lage sein sollte, ein Muster in den Codezeilen zu sehen, die in der Codebasis geändert werden. ZB gegen Ende eines Projekts, wenn der Code stabiler wird, sollte man sehen, dass weniger Codezeilen pro Zeiteinheit geändert werden.

Beispielsweise konnte man feststellen, dass in den ersten sechs Monaten des Projekts durchschnittlich 200 Codezeilen pro Tag und im letzten Monat 50 Codezeilen pro Tag und in der letzten Woche (kurz vor den Produkt-DVDs) verzeichnet wurden wurden ausgeliefert), wurden keine Codezeilen geändert (Code Freeze). Dies ist nur ein Beispiel, und je nach Entwicklungsprozess eines bestimmten Teams können unterschiedliche Muster auftreten.

Gibt es überhaupt Codemetriken (Literatur?), Die die Anzahl der modifizierten Codezeilen pro Zeiteinheit verwenden, um die Stabilität einer Codebasis zu messen? Sind sie nützlich, um ein Gefühl dafür zu bekommen, ob ein Projekt irgendwohin kommt oder noch lange nicht fertig ist? Gibt es Tools, die diese Informationen aus einem Versionskontrollsystem extrahieren und Statistiken erstellen können?

Eine Maßnahme, die Michael Feather beschrieben hat, ist " The Active Set of Classes ".

Er misst die Anzahl der hinzugefügten Klassen gegen die "geschlossenen". Der beschreibt den Klassenabschluss als:

Eine Klasse ist an dem Datum geschlossen, an dem von diesem Datum bis zur Gegenwart keine weiteren Änderungen daran vorgenommen wurden.

Er verwendet diese Kennzahlen, um Diagramme wie folgt zu erstellen:

Je kleiner der Abstand zwischen den beiden Linien ist, desto besser.

Möglicherweise können Sie eine ähnliche Kennzahl auf Ihre Codebasis anwenden. Es ist wahrscheinlich, dass die Anzahl der Klassen mit der Anzahl der Codezeilen korreliert. Es kann sogar möglich sein, dies zu erweitern, um eine Codezeilen-Kennzahl pro Klasse aufzunehmen, die die Form des Diagramms ändern kann, wenn Sie über einige große monolithische Klassen verfügen.

Solange es eine relativ konsistente Zuordnung von Features zu Klassen oder zu Dateisystemen gibt, können Sie so etwas wie eine Quelle in Ihr Versionskontrollsystem einbinden und sehr schnell erkennen, wo sich der größte Teil der Entwicklung befindet (und damit welche Teile des Codes am instabilsten sind).

Dies setzt voraus, dass Sie eine relativ ordentliche Codebasis haben. Wenn es sich bei der Codebasis um eine Schlammkugel handelt, werden Sie im Wesentlichen jeden kleinen Teil sehen, an dem aufgrund von gegenseitigen Abhängigkeiten gearbeitet wird. Das heißt, vielleicht ist das an sich (das Clustering während der Arbeit an einem Feature) ein guter Indikator für die Qualität der Codebasis.

Es wird auch davon ausgegangen, dass Ihr Unternehmen und das Entwicklerteam als Ganzes bestimmte Funktionen in der Entwicklung haben (seien es Zweige in der Versionskontrolle, jeweils eine Funktion, was auch immer). Wenn Sie beispielsweise an drei Hauptfunktionen in demselben Zweig arbeiten, führt diese Methode zu bedeutungslosen Ergebnissen, da Sie ein größeres Problem als die Codestabilität haben.

Leider habe ich keine Literatur, um meinen Standpunkt zu belegen. Es basiert ausschließlich auf meiner Erfahrung mit der Verwendung von Gource auf guten (und nicht so guten) Codebasen.

Wenn Sie git oder svn verwenden und Ihre Quellcode-Version> = 0.39 ist, ist es so einfach wie das Ausführen von gource im Projektordner.

Die Verwendung der Frequenz der modifizierten Zeilen als Indikator für die Codestabilität ist zumindest fraglich.

Die zeitliche Verteilung der modifizierten Linien hängt zunächst stark vom Software-Management-Modell des Projekts ab. Es gibt große Unterschiede in den verschiedenen Managementmodellen.

Zweitens ist das Unglück in dieser Annahme nicht klar - es ist die geringere Anzahl geänderter Zeilen, die durch die Stabilität der Software verursacht wird, oder einfach, weil die Frist abläuft und die Entwickler beschlossen, jetzt keine Änderungen vorzunehmen, sondern sie nach dem Ende der Frist vorzunehmen Freisetzung?

Drittens werden die meisten Zeilen geändert, wenn neue Funktionen eingeführt werden. Aber die neue Funktion macht den Code nicht stabil. Dies hängt von den Fähigkeiten des Entwicklers und der Qualität des Designs ab. Andererseits können sogar schwerwiegende Fehler behoben werden, wenn nur sehr wenige Zeilen geändert werden. In diesem Fall wird die Stabilität der Software erheblich erhöht, die geänderte Zeilenanzahl ist jedoch nicht zu groß.

Robustheit ist ein Begriff, der sich auf die korrekte Funktion eines Befehlssatzes bezieht, nicht auf die Quantität, Ausführlichkeit, Knappheit und grammatikalische Korrektheit des Texts, der zum Ausdrücken dieser Anweisungen verwendet wird.

In der Tat ist die Syntax wichtig und muss korrekt sein, aber alles darüber hinaus, was sich auf die gewünschte Funktion der Anweisungen bezieht, indem man sich die "Metriken" der Anweisungen ansieht, ist vergleichbar mit dem Plotten Ihrer Zukunft durch Lesen des Musters der Teeblätter am unteren Rand von Sie Teetasse.

Die Robustheit wird durch Tests gemessen. Unit-Tests, Rauch-Tests, automatisierte Regressionstests; Tests, Tests, Tests!

Meine Antwort auf Ihre Frage ist, dass Sie den falschen Ansatz verwenden, um eine Antwort auf einen der Robustheit zu finden. Es ist ein roter Hering, dass Codezeilen mehr bedeuten als Code, der Zeilen belegt. Sie können nur feststellen, ob der Code das tut, was Sie möchten, wenn Sie testen, ob er das tut, was Sie von ihm verlangen.

Bitte überprüfen Sie die korrekten Testgeschirre und vermeiden Sie die Mystik der Codemetrik.

Die besten Wünsche.