NDepend

Wie im letzten Post angekündigt wollte ich mich mit NDepend auseinandersetzen. Leider ist der Zeitabstand zwischen den Posts etwas größer geworden, da ich kaum Zeit finde mich zum Einen mit NDepend zu befassen und zum Anderen einen Artikel darüber zu schreiben

Interessant ist dieses Tool allemal. Mit NDepend kann man seine .NET Assemblies analysieren und sich diverse Infos zum Aufbau des Codes ausgeben lassen. Dabei wird man zu Beginn mit einer Reihe von Informationen überflutet die es auszuwerten gilt.

Für die Analyse muss man die Assemblies auswählen, die man betrachten will. Nach ein paar Sekunden bekommt man einen Bericht im Web-Browser angezeigt und die detaillierten Auswertungen in NDepend selbst.

Der Bericht im Browser zeigt im Prinzip alle Ergebnisse der Analyse an die man auch in NDepend selbst nachschauen kann. Man hat dadurch einen direkten Überblick über Lines of Code, Abhängigkeiten, verletzte Vorgaben wie z.B. überschreiten einer maximalen Methodenlänge. Was im Bericht angezeigt werden soll kann man in NDepend inklusive eigener Analyse-Abfragen konfigurieren.

An dieser Stelle kann man nun mit NDepend selbst arbeiten. Durch ein paar vorgegebene Constraints werden einem direkt Stellen im Programm angezeigt, die allem Anschein nach nicht gut designed sind oder irgend welche Vorgaben verletzen. Wenn das Projekt zu groß ist kann man sich langsam durch abgegrenzte Code-Bereiche hangeln bis dieser entsprechend überschaubar ist. Zu jedem Namespace, Typen und Methode kann man sich die direkten Abhängigkeiten anzeigen lassen.

Im Graphen sieht man welcher Typ genau von welchem anderen Typen abhängt. Will man den weiteren Aufbau sehen so kann man in eine Klasse "hinein Zoomen" um die inneren Abhängigkeiten zu betrachten.

Hier z.B. lasse ich mir den inneren Graphen von "Scrum.Org" anzeigen.
In der Matrix kann man noch genauer sehen, was von wem wie oft verwendet wird. Vom Namespace aus kann man immer weiter runter bis in die jeweilige Klasse navigieren analog zu der Graphenansicht.

Beide Ansichten zeigen zirkulare Abhängigkeiten an, markiert durch die dickeren Pfeile die im Graphen in beide Richtungen zeigen. In der Matrix werden diese mit einem roten Rahmen versehen. Um dies verwenden zu können setzt es voraus, dass man seine Applikation entsprechend nach Namespaces strukturiert hat. Ansonsten sind die Ergebnisse nicht wirklich aussagekräftig, siehe diskussion um NHibernate Codebasis

NDepend  bringt von Haus aus schon eine Menge vordefinierte Abfragen zur Codanalyse mit, die einem Assemblies, Namespaces, Typen, Methoden und Fields anzeigen, wenn der Code bestimmten Konditionen entspricht. Zum Beispiel wird angezeigt, wenn eine Methode zu lang ist. Dies kann mit der Hilfe von CQL (Code Query Language) auch selbst definiert werden.

Als Beispiel kann man mit:
SELECT TYPES WHERE NbFields > 20
alle Klassen anzeigen die mehr als 20 Fields beinhalten. So hat man jede Menge Möglichkeiten den Code nach unerwünschten Fragmenten zu durchsuchen. Man kann sogar die Testabdeckung ermitteln wenn man die Analysen von NCover oder MS VS Team System verwendet. Leider konnte ich diese Funktionialität noch nicht testen, da irgend wie der Import der NCover-Datei nicht den gewünschten Erfolg mit sich brachte.Vom gefundenen Ergebnis aus kann man direkt an die entsprechende Stelle im Quellcode "springen".

Wirklich toll fand ich die Abfrage nach der Komplexität einer Methode. Diese zählt Bedingungsoperatoren wie z.B. "if", "foreach" oder "&&". Daraus kann man formal ermitteln, wie komplex eine Methode ist. Zu jeder dieser Abfragemöglichkeiten gibt es auf der NDepend-Seite eine genaue Beschreibung und auch Ratschläge wie damit umzugehen ist.

Was mir jedoch bei der Ermittelung der Komplexität fehlte war die Einbeziehung der Schachtelungstiefe innerhalb einer Methode. Aber wenn ich das richtig sehe, kann man IlNestingDepth dafür verwenden.

Bei den ganzen Analysemöglichkeiten stellt sich mir nun die Frage, wann sollte ich jedesmal meinen Code analysieren? Vorallem wann sollte ich den Code entsprechend refaktorisieren? Denn Code der schon lange läuft, funktioniert und bei dem es keine Erweiterung gibt sollte meines Erachtens nicht refaktorisiert werden. Erst wenn ich an dieser Stelle etwas ändern will und ich einen Nutzen von den Refaktorisierungsmaßnamen habe macht dies auch Sinn, damit ich eine verbesserte Erweiterbarkeit habe. Alles andere wäre Refaktorisierung zum Selbstzweck und unter Umständen unnötig gefährlich.

Ich denke sinnvoll ist es die Analyse jedesmal durchzuführen, wenn man in einem Bereich mit einer Erweiterung beginnt und nachdem man fertig ist. Bei Beginn kann man direkt sehen, wo eine Refaktorisierung wichtig wäre. Wenn man seine Arbeiten abgeschlossen hat kann man formal kontrollieren, ob der Code den eigenen Ansprüchen genügt und eventuell direkt auf Schwachstellen reagieren.

Zum Abschluss will ich noch sagen, dass NDepend für mich lediglich einen sehr guten Anhaltspunkt bietet, wo man aufräumen sollte. Es werden stellenweise Sachen im Code bemängelt die bewußt so gestaltet wurden und troz der Warnung von NDepend gut organisiert sind. Ich werde mich in Zukunft noch weiter mit Code-Metriken beschäftigen und schauen, in wie weit man diese für eine bessere Codebasis verwenden kann.

Kurz bevor ich mit dem Artikel fertig wurde erhielt ich noch ein Liezenzupgrade für die neue 3er Version. Ich werde warscheinlich noch einemal in ein paar Wochen über die Neuerungen berichten.

Ihr könnt es ja einfach einmal selbst ausprobieren. Eine freie Version kann hier heruntergeladen werden.