Codeanalyse mit NDepend

Über Jan Welker habe ich vor einiger Zeit eine Lizenz von NDepend bekommen. Als Gegenleistung für die Lizenz sollte ich anschließend über meine Erfahrungen mit NDepend berichten. Hier also nun mein Erfahrungsbericht zu NDepend.

Anwendungsfälle

NDepend ist ein Werkzeug, dass Assemblies analysieren kann. Es ist eine eigenständige Anwendung, also kein Visual Studio Plugin, und arbeitet auf kompilierten Assemblies, nicht auf dem Quellcode.

NDepend kann z.B. dazu verwendet werden, Code auf mögliche “Schwachstellen” (im Sinne von Qualität, nicht Sicherheit) zu untersuchen. Es zeigt Stellen im Code, die man sich besser noch einmal genauer anschauen und möglicherweise ändern sollte.

Es lässt sich auch verwenden, um Grafiken und Berichte zu erzeugen, die helfen, die Architektur einer Anwendung zu verstehen. Anhand eines Abhängigkeitsgraphen ist z.B. darstellbar, wie Assemblies voneinander abhängen, also welche anderen Assemblies sie verwenden bzw. von welchen Assemblies sie verwendet werden. Diese Grafiken könnte man als Bestandteil der Entwicklerdokumentation verwenden, oder auch in Diskussionen mit anderen Entwicklern, wenn man über die Architektur der Anwendung spricht.

Eigene Erfahrungen

Ich habe NDepend bisher in zwei “echten” Projekten eingesetzt.

Das erste Mal habe ich NDepend verwendet, als ich eine Anwendung analysieren und Verbesserungsvorschläge für meinen Kunden erstellen sollte. In dem Projekt habe ich den Quellcode einer VB.NET Anwendung bekommen, an der mehrere Entwickler ca. 1 1/2 Jahre gearbeitet hatten. Es gab dazu keine Dokumentation, ich hatte nur kurz beim Kunden vor Ort einen Überblick über die Anwendung bekommen.

NDepend hat mir geholfen, die Anwendung besser zu verstehen. Zwar bestanden die Anwendungen (ich meine das Projekt bestand aus 3 Anwendungen, wenn ich mich noch richtig erinnere) zwar jeweils aus nur einer einzigen Assembly, aber wenigstens wurden innerhalb der Assembly Namespaces sinnvoll eingesetzt. Dank NDepend konnte ich sehen, aus welchem Namespace welche anderen Namespaces verwendet wurden, welcher Typ welche anderen Typen verwendet hat usw., und habe so einen guten Überblick über die Struktur des Projekts bekommen.

Das zweite Projekt, bei dem ich NDepend eingesetzt habe, war eine ASP.NET Intranetanwendung, an der ich die letzten vier Monate zusammen mit fünf anderen Entwicklern gearbeitet habe. In diesem Projekt habe ich NDepend verwendet, um Stellen im Code zu finden, die wir noch einmal überarbeiten sollten. Insbesondere habe ich damit kontrolliert, ob zwischen den einzelnen Assemblies unserer Anwendung keine unnötigen Abhängigkeiten bestehen.

Wir haben in unserem Projekt sehr viele einzelne Komponenten erstellt, die nicht fest aneinander gekoppelt, sondern durch Interfaces getrennt sind, und später über Dependency Injection mit Unity zusammengesetzt werden. Dank NDepend konnte ich einige Stellen finden, wo versehentlich Typen direkt (statt über ihre Interfaces) verwendet wurden. Teilweise waren Typen auch in “falschen” Assemblies definiert, durch das verschieben in passendere Assemblies konnte ich einige unnötige Abhängigkeiten zwischen den Assemblies der Anwendung entfernen.

Beispiel

Da ich ein Kundenprojekt schlecht als Beispielprojekt online stellen kann habe ich Microsofts ASP.NET MVC Beispielanwendung Oxite einmal mit NDepend analysiert.

Zunächst habe ich ein neues NDepend Projekt erstellt. Zu diesem Projekt habe ich die zu analysierenden Assemblies von Oxite hinzugefügt – NDepend kann dazu einfach alle Assemblies einer Visual Studio Solution zum Projekt hinzufügen. NDepend unterscheidet bei den Assemblies zwischen “Application Assemblies” (Teil der Anwendung) und “Tier Assemblies” (.NET Framework und sonstige Bibliotheken).

Um verschiedene Versionen einer Anwendung vergleichen zu können und zu vergleichen, wie sich die verschiedenen Metriken seit der letzten Version geändert haben, kann man die Ergebnisse einer Analyse speichern und dieses Ergebnis mit der nächsten Analyse vergleichen. Es ist außerdem möglich, Code Coverage Daten aus NCover oder Visual Studio Team System einzubinden. PartCover wird leider nicht unterstützt.

Das Ergebnis der Analyse lässt sich zum einen in NDepend selbst betrachten, und es ist möglich, einen HTML Report zu generieren.

Einige Screenshots mit den Analyseergebnissen in VisualNDepend:

Ein sehr mächtiges Werkzeug zur Codeanalyse sind die CQL-Queries. CQL ist so eine Art “SQL für Code”, mit der sich Anfragen wie “Welche Methoden sind länger als x Zeilen?” oder “Welche Methoden haben mehr als 10 Parameter” formulieren lassen. Die wichtigsten Abfragen sind in NDepend bereits enthalten, natürlich lassen sich auch eigene definieren.

Mehr Beispiele zu den CQL Queries gibt es direkt im NDepend Beispiel-Report zu Oxite – oder natürlich direkt in NDepend. Unter http://www.ndepend.com/ gibt es eine Testversion. Für akademische Projekte und Open Source Software ist NDepend kostenlos.