Technische Schulden verfolgen mit NDepend 2017.2

NDepend nutzte ich mittlerweile häufig zur Analyse meiner Anwendungen. Die statische Codeanalyse liefert zwar kein vollständiges Bild zum Zustand einer Anwendung, aber man erhält genügend Informationen um Probleme frühzeitig zu erkennen. Die früheren Versionen hatte ich bereits hier und hier beschrieben.
Technische Schulden verfolgen mit NDepend 2017.2 weiterlesen

Code mittels NDepend analysieren

Um möglichst schnell in ein komplexeres Projekt einzusteigen hilft einem eine gute Übersicht. Visual Studio bietet je nach Ausgabe eine recht gute Code Analyse. Will man mehr wissen oder ist man an bestimmten Konstellationen im Code interessiert, stösst man aber schnell an Grenzen. Hier benötigt man einmal mehr die Werkzeuge und Ergänzungen von Drittherstellern.

Als ich vor einigen Wochen gebeten wurde mir NDepend anzuschauen kam mir dies sehr gelegen. NDepend ist ein Tool zur statischen Code Analyse für .Net. Damit lässt sich der Code nicht nur auf vorgefertigte Qualitätskriterien überprüfen, sondern man kann auch eigene Abfragen definieren.

 

Download und Installation

Auf NDepend.com kann man die Demo-Version als Zip herunterladen. Die Installation beschränkt sich aufs entpacken der Datei und einem Doppelklick auf die Installationsdatei.

Wenn einem die Möglichkeiten von NDepend gefallen bekommt man eine entsprechende Lizenz ab 299€. Leider gibt es keine GUI-basierende Möglichkeit um den Lizenzschlüssel einzugeben. Die Lizenzdatei muss man in den entpackten Ordner kopieren bevor man Visual Studio startet. Sonst wird nach Ablauf der Evaluationsperiode NDepend beim nächsten Start von Visual Studio deinstalliert.

Läuft NDepend genügt es das gewünschte Projekt in Visual Studio zu öffnen und über den Menüpunkt „NDepend“ die Analyse zu starten. Dieser Vorgang ist zwar recht schnell, kann je nach Projektgrösse aber dennoch einige Minuten dauern.

 

HTML-Report

Das erste was einem als Resultat begegnet ist der HTML-Report. Dieser enthält die wichtigsten Punkte und soll als Zusammenfassung fürs Management dienen. Leider ist die Funktionalität äusserst beschränkt und damit einzig als Druckversion für die Gesamtsicht zu gebrauchen.

NDepend Report

 

Visual NDepend

Mit Visual NDepend hat man ein deutlich besseres Werkzeug zur Verfügung. Hier kann man die Grafiken genauer anschauen und auch einzelne Klassen auf der TreeMap finden. Klickt man auf Klassen- oder Methodennamen öffnet sich Visual Studio und zeigt einem die passende Stelle an.

Da alle Funktionen nur hier schön zusammengefasst werden dürften die meisten Benutzer vor allem mit Visual NDepend arbeiten. Man hat zwar immer noch den Wechsel zwischen Visual Studio und Visual NDepend, dafür kommt man aber sehr schnell zu den gewünschten Informationen.

Visual NDepend

 

Integration in Visual Studio

Die Integration in Visual Studio ist sehr gut und man kann mittels Rechtsklick auf eine Klasse die einzelnen Auswertungen direkt aufrufen. Bei der Gesamtübersicht wurde auf dem Dashbard allerdings nicht alles aus Visual NDepend übernommen. Es ist zwar alles in Untermenüs vorhanden, aber bis man die einzelnen Grafiken findet kann es dauern…

NDepend VS2013

 

Eigene Abfragen

NDepend glänzt vor allem durch die Abfragesprache CQLinq. Damit kann man selber den Code nach eigenen Kriterien durchsuchen (wie mehr als 4 Methoden mit mehr als 3 Parameter und mehr als 10 Attribute pro Klasse). Hat man gewisse Konstellationen entdeckt die häufig zu Problemen führen hilft einem CQLinq beim aufspüren.

Die Dokumentation zu CQLinq ist sehr ausführlich und sollte vor dem Experimentieren konsultiert werden. Die Hilfestellung bei Fehlern im Editor ist nicht gerade optimal und da die Abfragen immer gleich ausgeführt werden wird man sehr schnell mit Fehlermeldungen eingedeckt.

NDepend Query Editor

 

Verbesserungspotential

Die Inkonsistenzen der 3 Ansichten (HTML-Report, Visual NDepend und Visual Studio) sind nicht gerade Benutzerfreundlich. Hat man sich einmal daran gewöhnt kann man damit arbeiten. Allerdings ist es schade wenn man viel Zeit mit der Suche nach einer bestimmten Auswertung verliert nur weil sich diese in einem anderen Tool befindet.

Mit einer verständlicheren Kategorisierung der Fehler könnten die Reports auch dem Fachdienst bei der Beurteilung helfen. Code Climate schafft dies mit der Benotung A bis F für einzelne Klassen. Während ein A sehr gut ist gilt ein F als dringend zu verbessern. Zudem wird schön aufgezeigt wie sich der Code über die Zeit entwickelt, was einen zusätzlichen Motivationsschub gibt. Leider fehlen solche einfachen Werte bei NDepend, auch wenn Ansätze zum Verfolgen der Veränderungen vorhanden sind.

 

Fazit

NDepend ist ein tolles Tool für Entwickler die mehr über ihren Code wissen wollen. Um die Möglichkeiten voll auszuschöpfen wird man aber einiges an Zeit investieren müssen um selber CQLinq Abfragen zu erstellen.

Ausserhalb der Entwicklung sind die Einsatzmöglichkeiten von NDepend allerdings sehr beschränkt. Die Probleme bei der Benutzerführung und die Inkonsistenzen sind wie die Reports wenig hilfreich um mit dem Fachdienst über Qualitätsverbesserungen zu diskutieren.

Buch-Rezension zu „Code Complete 2nd Edition“

Code Complete 2nd editionCode Complete – A Practical Handbook of Software Construction (2nd edition)“ von Steve McConnell gilt als Standardwerk das man unbedingt gelesen haben muss. Es behandelt alle wichtigen Themen der Softwareentwicklung und gewann zahlreiche Preise.

Nach langem fand ich doch noch die Zeit um dieses Buch zu lesen. Allerdings fragte ich mich sehr bald ob die Empfehlungen auf Amazon vom gleichen „Code Complete“ handeln. Entgegen der weit verbreiteten Meinung hatte ich kein praktisches Handbuch vor mir, sondern die ausführlichste Auflistungen von Studien die ich je gesehen habe. Nach zahlreichen weiteren Entdeckungen kann ich von diesem Buch nur abraten.

 

Solider 1. Eindruck

Liest man das Inhaltsverzeichnis durch sieht man dass alle wesentlichen Teile der Erstellung von Software in diesem Buch behandelt werden. Wie McConnell im Vorwort schreibt geht es ihm um eine ausgewogene Diskussion und nicht um Hype. Dies tönt vielversprechend und durchs ganze Buch hinweg untermauert er seine Aussagen mit Studien.

Die zahlreichen Diagramme helfen einem beim Verstehen der gerade vorgestellten Ideen und die Checklisten sind ein guter Ausgangspunkt um die gewonnenen Erkenntnisse im eigenen Code umzusetzen.

Versucht man allerdings mit dem Buch zu arbeiten bemerkt man schnell die ersten Probleme.

 

Genauer hingeschaut

Die objektive und ausgewogene Diskussion erreicht McConnell durch das Referenzieren von Studien. Über die ersten Kapitel hinweg erweckt dies einen sehr professionellen Eindruck. Bis man feststellt das McConnell einen Artikel eines gewissen „McConnell, S.“ zitiert. Einen eigenen Artikel zu zitieren ist ja kein Problem, doch sollte man auf diesen Punkt hinweisen. Dies wäre besonders wichtig wenn es sich um ein eher kontroverses Thema handelt und der eigene Artikel der einzige Text ist der die eigene These stützt.

Richtig interessant wird es aber erst wenn die einzige Studie zu einem Thema unübersehbar falsch ist. Auf Seite 518 werden die Fehlerarten gemäss der Studie von Boris Beizer von 1990 aufgeführt. Es wurde dabei so genau gearbeitet dass die Prozentwerte auf 2 Nachkommastelen genau ausgewiesen werden. Dies obwohl die Studie nur die Resultate anderer Studien kombinierte und deren Werte mehr als 50% voneinander abweichen. Auf all diese Fehler weist McConnell explizit hin. Seine Schlussfolgerung daraus ist, die Werte mögen so nicht stimmen aber die Richtung ist in Ordnung. Er verwendet diese Werte danach um seinen Punkt zu beweisen – allerdings ohne die Nachkommastellen…

Wenn man so mit Studien arbeitet kann man auch gleich darauf verzichten. Dieses Beispiel ist das offensichtlichste, allerdings gibt es noch zahlreiche weitere Stellen wo die Resultate so lange verdreht werden bis der gewünschten Punkt „bewiesen“ ist.

 

Zu kurz

Obwohl das Buch rund 960 Seiten hat ist es viel zu kurz um die Fülle an Themen auch wirklich zu erklären. Lässt man das Vorwort, den Anhang, die einzelnen Verzeichnisse, die Checklisten und die Zusammenfassungen weg bleiben für jedes der 35 Kapitel nur noch 20 Seiten übrig. Das reicht in der Regel nur um das jeweilige Thema kurz anzuschneiden.

Besonders deutlich wird dies beim Kapitel „Refactoring„. Die Gründe für Refactoring werden von McConnell sehr gut dargelegt, gleiches gilt für mögliche Strategien. Wie man allerdings den eigenen Code umbauen soll bleibt unklar. Zu mehr als 2-3 Sätzen pro Refactoring-Technik reicht der Platz in diesem Kapitel nicht. Der Praxisnutzen ist dementsprechend gering und das Vorgehen für Refactorings erschliesst sich nur den Lesern, die den zu vermittelnden Inhalt bereits kennen. Da könnte man das Kapitel eigentlich gleich ganz weg lassen.

Leider ist dieser Platzmangel nicht auf ein Kapitel beschränkt sondern zieht sich durchs ganze Buch.

 

Wo es gefährlich wird

Der lockere Umgang mit Studien und der zu knappe Platz um ein Thema wirklich zu erklären birgt ein grosses Gefahrenpotential. Dies wird besonders bei den Kapiteln 25 und 26 deutlich, wo das Thema „Code-Tuning“ behandelt wird.

Nach einem Hinweis über die Wichtigkeit von Messungen zu Beginn der Optimierung (Baseline) beginnt eine kaum enden wollende Reihe von Mikro-Optimierungen. Ist es schneller eine Schlaufe zum zuweisen der Array-Werte zu verwenden oder sollte man diese einzeln aufschreiben? Soll man bei verschachtelten Schlaufen zuerst über die innere oder über die äussere Schlaufe iterieren?
Zu all diesen Fragestellungen gibt es einen Codeschnipsel und eine Tabelle. Je nach Sprache und Problem variiert die Grösse der Einsparmöglichkeiten oder ist sogar negativ. Es fehlt einzig ein Hinweis wie diese Werte zustande kommen.

Erst nach gut 50 Seiten dieser Mikro-Optimierungen erklärt McConnell wie er diese Werte berechnet hat:

[For the first edition] I ran most of the tests in this chapter 10‘000 to 50‘000 times to get meaningful, measurable results. For this edition I had to run most tests 1 million to 100 million times. When you have to run a test 100 million times to get measurable results, you have to ask whether anyone will ever notice the impact in a real program.

Diese Fragestellung hätte McConnell zu Beginn des Kapitels aufwerfen müssen. So allerdings erklärt man den Lesern erst ausführlich wie gross die Unterschiede zwischen den einzelnen Varianten sind obwohl diese in der Realität keine Bedeutung haben.
In der Folge davon darf man in unzähligen Projekten grosse Diskussionen über die Reihenfolge von Schlaufen führen. Denn schliesslich hat McConnell ja gezeigt das dieser Ansatz 73% schneller ist…

 

Alternativen

Wer seine Lesezeit sinnvoller verwenden will sollte sich diese 3 Bücher anschauen:

Lässt man die Anhänge weg sind diese Bücher zusammen auch rund 960 Seiten lang. Allerdings werden hier die jeweiligen Themen praxisnah und verständlich beschrieben.

 

Fazit

Auf den ersten Blick ist „Code Complete“ ein sehr gutes Buch mit zahlreichen interessanten Ideen. Betrachtet man es genauer sieht man sehr bald die vielen Unstimmigkeiten. Aus einer objektiven Darstellung wird so ein zurechtrücken von Studien und durch die vielen angeschnittenen Themen fehlt der Platz um einen wirklichen Praxisnutzen zu vermitteln.

Für Einsteiger ist dieses Buch dadurch nicht geeignet und durch die realitätsfremden Mikro-Optimierungen sogar gefährlich. Und wer sich mit der Thematik bereits auskennt wird kaum etwas Neues finden. Statt „Code Complete“ liest man besser die 3 alternativen Bücher, da hat man am Ende auch etwas mit Praxisbezug gelernt.

 

Zum Buch

Code Complete – A Practical Handbook of Software Construction (2nd edition)“ von Steve McConnell, 2004 Microsoft Press, ISBN 978-0-7356-1967-8, 960 Seiten, Englisch

 

Buch-Rezension zu „The Art of Unit Testing (2nd Edition)“

The Art of UnitTesting 2nd editionSeit Ende letzter Woche gibt es mit „The Art of Unit Testing, Second Edition“ eine neue Ausgabe meines favorisierten TDD-Buches. Die erste Ausgabe erschien 2009 und beeinflusste mein Verständnis von Test-Driven Development nachhaltig.

Ich war einerseits gespannt auf die neue Ausgabe und andererseits auch ein wenig unentschlossen ob es wirklich eine neue Ausgabe benötigt. Konnte die neue Ausgabe die kleineren Mankos der 1. Ausgabe wirklich beheben? Oder gibt es am Ende ein ganz anderes Buch das nur den gleichen Namen trägt?

 

Aufbau beibehalten, Inhalt überarbeitet

Die Kapitelstruktur der 2. Ausgabe unterscheidet sich nur minimal von der 1. Ausgabe. Der ehemalige Anhang A „Design and testability“ ist nun ein „richtiges“ Kapitel und Mock-Frameworks werden in einem zusätzlichen Kapitel noch eingehender angeschaut. Die übrigen Kapitel blieben alle erhalten und wer sich nur am Inhaltsverzeichnis orientiert wird diese 2. Ausgabe wohl schnell wieder weglegen.

Die grossen Neuerungen finden sich in den Kapitel selber. Diese wurden komplett überarbeitet und liefern nun eine noch bessere Erklärung wieso man seine Unit Tests auf diese Art organisieren und strukturieren soll. Die Beispiele sind nun so gut dass man dieses Buch auch problemlos einem Anfänger geben kann. Roy Osherove führte zwischen den 2 Büchern zahlreiche TDD-Kurse durch und hat seine dabei gewonnenen Erkenntnisse in die 2. Ausgabe einfliessen lassen. Dadurch wurde auch hinsichtlich der Praxistauglichkeit nochmal ein Schritt nach vorne gemacht, was sich vor allem an den viel klareren Namensregeln zeigt.

Wenn man die erste Ausgabe kennt und täglich mit Unit Tests arbeitet wird man fast nur bei den Mock-Frameworks neue Erkenntnisse bekommen. Die aktuelle Liste lieferte einem eine gute Übersicht und kann einem auch helfen sich gegen ein bestimmtes Framework zu entscheiden:

MSFakes might be free and included with Visual Studio, but it will cost you a lot of money down the line in developer hours, fixing and trying to understand your tests.

Wer seine erste Ausgabe nicht nur als Staubfänger nutzt sollte sich die 2. Ausgabe zulegen. Ob man das Buch als Nachschlagewerk, zum Auffrischen seiner Unit Testing Kenntnisse oder für neue Teammitglieder braucht – die überarbeiteten Kapitel sind einfacher zu verstehen und näher an der Praxis.

 

Fazit

Mit der 2. Ausgabe konnte Roy Osherove die hohen Erwartungen übertreffen und ein noch besseres Buch über Unit Testing liefern. Die darin beschriebenen Vorgehensweisen helfen in der Praxis die Unit Tests im Griff zu behalten und eine Struktur hinein zu bringen. Wenn man die erste Ausgabe besitzt und damit noch arbeitet lohnt sich auch der Kauf der 2. Ausgabe.

 

Zum Buch

The Art of Unit Testing, Second Edition“ von Roy Osherove, November 2013 Manning, ISBN 978-1-6172-9089-3, 296 Seiten, Englisch