Just about .Net

Seit einigen Wochen nutze ich NDepend als logische Erweiterung zum Resharper und Style Cop. Während der Resharper dafür sorgt, dass sich alle Entwickler an die gleichen Regeln halten. Kann ich mit NDepend zum einen prüfen ob sich auch wirklich an die Regeln gehalten wird, vor allem aber ob die Ideen hinter den Regeln auch korrekt umgesetzt werden.

Der eigentliche Auslöser für die Nutzung von NDepend war aber ein anderer. Es ging viel mehr darum eine Anwendung mit sehr „interessanter“ Codebasis soweit zu refaktorisieren, dass ihre innere Struktur nicht durch jede Änderung gleich ins Wanken gerät. In wie weit dieser Anspruch erfüllt wurde sei jetzt einmal dahin gestellt. NDepend hat aber auf alle Fälle dabei geholfen den Ist-Stand zu visualisieren.

Nach der ersten Analyse bin ich dann fast vom Stuhl gefallen als ich die Menge an Warnhinweisen gesehen habe. Auf den zweiten Blick musste ich aber erkennen, dass davon auch einige unberechtigt waren. Dies ist aus meiner Sicht auch ein Kritikpunkt an NDepend: Dank der Query-Sprache die es benutzt, kann man mit NDepend sehr dynamische Abfragen fahren, zu Beginn bekommt man aber schon einen so großen Satz an Abfragen die nicht unbedingt auf das eigene Projekt anwendbar sind, dass man leicht die Übersicht verliert.

Ein Beispiel ist hier die standardmäßig aktivierte Query, mit welcher die Verwendung des s_ für statische Felder vorgeschrieben wird. Eine solche Vorgabe ist mir bisher nicht untergekommen, schlägt sich aber zunächst negativ in meiner Auswertung nieder. Ähnlich geht es mir auch mit der Query die besagt, man solle nicht weniger als fünf Typen in einem Namensraum haben. Die Intention der Query verstehe ich, aber die Zahl Fünf ist hier recht hoch gegriffen und führt ebenfalls schnell zu Warnungen, die darüber hinaus auch noch als kritisch gelten.

Aus diesem Grund habe ich anfangs systematisch Regeln abgeschaltet und so geändert, dass sie nur meinen Code betreffen. Für letzteres muss man den Ausgangspunkt einiger der Queries von zum Beispiel
from t in Application.Types
zu
from t in JustMyCode.Types
ändern. In den JustMyCode Queries, von denen es 4 gibt, kann man dann auch weitere Einschränkungen vornehmen um generierten Code von der Auswertung auszunehmen.

Auf diese Weise sanken die Regelbrüche auch schon deutlich, wobei es natürlich immer noch viel zu viele sind. Basierend auf den Auswertungen kann ich nun aber systematisch Brandherde identifizieren und löschen, bevor sie sich zu größeren Problemen erwachsen. Damit kommen wir auch zu den, aus meiner Sicht, größten Vorteilen von NDepend. 1. Finde ich Problemstellen schneller und 2. kann ich dem Kunden gegenüber auch nachweisen was ich getan habe.

Letzteres ist beim Refactoring von Anwendungen immer wieder eine Herausforderung. In den seltensten Fällen sieht der Endanwender eine Verbesserung in seiner Oberfläche, da fast alle Anpassungen im Hintergrund laufen. Management und Kunde müssen den Entwicklern also vertrauen, dass diese sinnvoll handeln und nicht die freigegebene Zeit nutzen um im Internet zu surfen. Dank NDepend kann man die Fortschritte mess- und vor allem darstellbar halten. Also selbst wenn sich an der UI nichts Neues ergibt, sieht man in Form von Charts die Verbesserung. Diese Transparenz schafft dann auch das Vertrauen um zukünftige Verbesserungen an der Codebasis zu rechtfertigen. Hierbei hilft dann auch der Vergleich von Builds und/oder Baselines. Bei diesen Vergleichen werden die einzelnen gemessenen Werte für jeden Vergleichsgegenstand gegenüber gestellt und der Unterschied visualisiert.

Abschließend lässt sich also sagen, dass ich NDepend sehr gern einsetze um mich in wirklich großen Codebasen zurecht zu finden. Es hilft mir bei der Kommunikation mit dem Kunden, will aber auch ersteinmal gebendigt werden. Bei Letzterem gibt es definitiv Verbesserungspotential. So wäre es wünschenswert wenn man die gängigen Styl Cop Rules oder andere Arten der Konfiguration nutzen könnte, statt unbedingt auf die NDepend eigene Query-Sprache zugreifen zu müssen. Auch fand ich es schade, dass man keine Code Coverage über NCrunch ermitteln kann, wobei dies zu verschmerzen ist wenn man die Coverage Daten aus dem entsprechenden Build vom Server nutzt.

Ob sich NDepend demnach unbedingt für jeden Entwickler eignet, halte ichfür fraglich. Aus meiner Sicht unterstützt es eher Team Leads oder Architekten. Es ist kein Werkzeug, das man tagtäglich verwendet, sondern eher bei ausgedehnten Reviewsessions oder um gezielt Refactorings zu überwachen.