Abhängigkeiten im Code aufzeigen mit NDepend 2020

NDepend ist ein praktisches Werkzeug zur statischen Codeanalyse. Die grosse Neuerung in der Version 2020 ist der komplett überarbeitete Abhängigkeitsgraph. Ich hatte bereits mehrmals über NDepend geschrieben (hier, hier und hier) und möchte nicht mehr darauf verzichten.

Der alte Abhängigkeitsgraph

Bisher konnte man die Grafik auf der obersten Ebene nur bedingt beeinflussen. Man konnte wählen zwischen «Allem» und «eigenem Code». Für eine Gesamtübersicht hat sich die Beschränkung auf den eigenen Code aufgedrängt, da schon bei mittleren Projekten die Details nur sichtbar waren, wenn man hineingezoomt hat:

Im Gegensatz dazu konnte man den eigenen Code meist ohne Probleme anschauen:

Von hier aus konnte man sich über die Pfeile nach unten bewegen und so immer mehr Details erkunden. Dieses hin und her hat mir über Jahre hinweg gute Dienste erwiesen.

Der neue Abhängigkeitsgraph

Mit Version 2020 können wir die Auswahl viel granularer vornehmen und von Assemblies über Namespaces zu Typen bis hinunter zu den Methoden alles anzeigen lassen. Öffnet man nun den Graphen, so wird einem die Sicht auf die Typen angezeigt:

Man kann aber ganz leicht über die Navigation direkt oberhalb der Anzeige auf die Assemblies wechseln:

Die neue Darstellung hilft einem beim Abklären von Abhängigkeiten deutlich besser als es die alte Version tat. Man wechselt zwischen den gewünschten Sichten hin und her, ohne dabei Zeit zu verlieren. Sehr praktisch ist aus meiner Sicht auch die Exportfunktion, wo neben PNG auch SVG unterstützt wird. So bekommt man eine verlustfreie Darstellung zur Verwendung ausserhalb von NDepend.

Wo geht es zurück?

Wenn man sich durch den Graphen klickt möchte man irgendwann mal zurück zur Übersicht. Diese erreicht man über den Link «application map» ganz links in der Navigation:

Hat man allerdings ein Element selektiert, sieht die Navigation anders aus und es fehlt der Link zur «application map». In dem Fall genügt es zuerst auf «unselect» zu klicken, damit man die initiale Navigation bekommt:

Zirkuläre Abhängigkeiten in Namespaces finden

Während Visual Studio und der Compiler einem vor zirkulären Abhängigkeiten zwischen Assemblies warnen kann, sind solche Abhängigkeiten in Namespaces schwer zu finden. Mit NDepend findet man zirkulären Abhängigkeiten dank der farblichen Hervorhebung sehr schnell und ohne lange zu suchen. Die rote Farbe auf dem Graph fällt auch bei komplexeren Projekten sofort auf:

Fazit

Der Abhängigkeitsgraph ist nicht die einzige Neuerung von NDepend 2020, doch für mich die wichtigste. Allein damit rechtfertigt sich aus meiner Sicht bereits ein Update auf die neuste Version. Die übrigen Verbesserungen und die neuen Regeln zur Qualitätskontrolle runden den guten Eindruck ab, auch wenn einem diese erst bei der längeren Benutzung auffallen.

Buch-Rezension zu „Java by Comparison“

„Java by Comparison“ von Simon Harrer, Jörg Lenhard und Linus Dietz erschien 2018 bei The Pragmatic Programmers. Dieses Buch wagt sich an eine grosse Herausforderung: Wie kann man das über Jahre angeeignete Expertenwissen in einfacher Form Programmier-Anfängern zugänglich machen?

Mein Technologieradar für 2017

Mit dem neuen Jahr wird es auch wieder Zeit für eine Aktualisierung meines Technologieradars. Nach den Ausgaben für 2014 und 2015 verzichtete ich auf eine Ausgabe für 2016. Die grossen Ankündigungen von Microsoft (wie ASP.Net vNext) verzögerten sich und nur die Jahreszahl anzupassen war mir zu wenig.

10 äusserst sehenswerte Videos der NDC Oslo

Auch 2 Monate nach der NDC Oslo stosse ich noch immer auf zahlreiche Referenzen und Zitate aus den dort gehaltenen Präsentationen. Dies erstaunt mich angesichts der hohen Qualität der Konferenz und der Referenten nicht wirklich. Seit die Videos auf Vimeo aufgeschaltet sind bin ich selber auch fleissig am Anschauen.

Bei total 150 Präsentationen kann ich mich wohl noch einige Wochen beschäftigen. Da nicht jeder so viel Zeit hat habe ich hier die 10 Präsentationen zusammengetragen die ich äusserst sehenswert finde.

 

„Clean Architecture and Design“ und „Principles of Component Design“ von Robert C. Martin behandeln die Themen die im Workshop zu „Clean Architecture“ eingehend behandelt wurden. Wer seine Software nicht einem Framework unterordnen will findet hier einen passenden Ansatz.

 

Allan Kelly zeigt in „Do it right, then do the right thing“ wieso man sich besser darauf konzentrieren soll die Dinge richtig zu machen. Macht man die Dinge richtig ist es viel einfacher die richtigen Dinge anzugehen. Der so oft propagierte Weg erst die richtigen Dinge zu machen funktioniert nur bis zur nächsten Management-Theorie, dann gibt es ein neues „richtig“ und alles was man bisher machte war „falsch“. Und wie oft die Theorien wechseln hat wohl jeder schon selber mitbekommen.

 

„Abusing C#“ von Jon Skeet zeigt einem in einer Stunde was man alles mit C# anstellen kann und einem garantiert nichts bringt. Dies macht Skeet allerdings so lustig das man dieses Video unbedingt gesehen haben muss. Und wenn man genau zuhört kann man doch noch das eine oder andere über die Implementierung verschiedener .Net Features lernen…

 

Liz Keogh zeigt in „Don’t let your process hide your ignorance“ wie wir überall versuchen unsere Unkenntnisse durch eine übertriebene Prozesstreue zu kompensieren. Aber genau da wo wir noch nie mit einem Projekt zuvor waren liegt oft der Wert des neuen Projekts. Dieses Neue benötigt unsere Aufmerksamkeit und hier wird sich entscheiden ob unser Projekt ein Erfolg oder ein Fehlschlag wird. Aus meiner Sicht ist dies das beste Video darüber was „agil“ eigentlich bedeutet.

 

In „Being an Anti-social Geek is harmful“ zeigt Hadi Hariri wie wichtig Kommunikation ist. Dies gilt nicht nur für Business-Analisten, sondern auch für Entwickler. Wie schnell man schon in Englisch aneinander vorbei spricht zeigte er mit der Grafik „What British People Say, Versus What They Mean„. Wer schon einmal einen Dialog von SAP gesehen hat weiss was passieren kann wenn ein Entwickler nicht mit dem Benutzer kommuniziert…

 

Gojko Adzic zeigt in „Make Impacts, Not Software“ wie Veränderungen in der Umgebung massive Auswirkungen auf unsere Annahmen und Anforderungen haben. Die Vasa dient dabei als perfektes historisches Beispiel (“The ship was shipped – but not very far…“) für die veränderlichen Zeiten in denen wir uns bewegen. Ein GPS für Projekte ist nur eine von vielen seiner Ideen die in dieser Präsentation zum Überdenken der eigenen Abläufe anregt.

 

Wie Bodil Stokke in „What Every Hipster Should Know About Functional Programming“ zeigt kann man eine Präsentation auch in Klingonisch starten. Nach diesem kleinen Spass zur Einleitung erklärt sie sehr verständlich all die vielen verwirrenden Begriffe rund um die funktionale Programmierung (wie Functors). Eine äusserst hilfreiche Präsentation für alle die einmal etwas abseits von OO probieren wollen.

 

In „TDD, where did it all go wrong“ zeigt Ian Cooper die häufigsten Probleme bei TDD. Er führt dabei all die bei so vielen (TDD-) „Fanatikern“ hochgehaltenen Praktiken auf und zeigt wie weit diese von den ursprünglichen Ideen von Kent Beck entfernt sind. Wer „TDD by Example“ schon kennt sollte nach dem anschauen des Videos unbedingt nochmals das Buch hervorholen. Es ist erstaunlich was alles von Kent Beck vor 10 Jahren beschrieben wurde und heute wieder als die Lösung der TDD-Probleme aufgeführt wird.

 

Andy Hunt zeigt in „Uncomfortable with Agility: What has Ten+ Years got us?“ was in den letzten 10 Jahren in der agilen Software Entwicklung so alles geschehen ist. Wer schon immer wissen wollte wie das agile Manifest entstanden ist und was die Motivation war wird hier fündig. Die Erinnerungen von Andy Hunt über die damalige Zeit und ihre Hoffnungen ist eine äusserst spannende Geschichtslektion. Und es motiviert einem über die eigene Definition von „agil“ nachzudenken.

 

Soweit die 10 Videos die ich besonders hervorheben möchte. Über zusätzliche Empfehlungen würde ich mich freuen.

Von fachlichen und technischen Daten

In einer Geschäftsanwendung werden vor allem fachliche Daten bearbeitet. Daneben gibt es aber eine ganze Reihe von technischen Daten (wie einer ID oder einem Erstelldatum). Diese beiden Arten von Daten können problemlos nebeneinander abgelegt werden. Sobald man allerdings beginnt die Grenzen zu verwischen fangen die Probleme an.

Bis sich die Auswirkungen dieser Vermischung bemerkbar machen kann man sich meist nicht mehr an die dazugehörigen Entscheidungen erinnern. So beginnt ein mühsames Suchen nach den Ursachen von teils äusserst seltsamen Fehlern.

Ich will gar nicht zusammenrechnen wie viele Stunden ich so verloren habe. Dabei waren es zu Beginn jeweils ganz kleine Entscheidungen die am Ende zu solchen Problemen führten. Wie klein die sein können soll das nachfolgende fiktive Beispiel rund um Auftragsformulare zeigen.

 

Wenn aus technischen Daten fachliche werden…

Meist beginnt alles mit einer kleinen zusätzlichen Anforderung. Neu soll beispielsweise das Eingangsdatum eines Formulars geführt werden. Man kann nun ein zusätzliches Feld „Eingang“ anlegen oder den Wert ins Feld „Erstellt“ hineinschreiben. Das ist ja für die Anwendung das gleiche, da alle Formulare beim Eintreffen erfasst werden.

Allerdings wird das Feld „Erstellt“ durch die Anwendung hinweg immer als technisches Feld betrachtet das man weder auf der Oberfläche anzeigt noch irgendwie sonst verwendet. Damit ist es nun vorbei. Für das Objekt „Formular“ wird das Feld „Erstellt“ nicht nur angezeigt sondern auch noch gleich umbenannt – allerdings nur auf der Oberfläche. Und in den Reports. Und im Export. Und bei allen anderen zukünftigen Verwendungen dieses Objekts.

 

… und dies zu Problemen führt

Die Sonderregelung für „Formular“ ist zu diesem Zeitpunkt schon aufwändig aber noch kein Problem. Dazu braucht es meist noch eine kleine Veränderung der Geschäftsabläufe, wie einer externen Erfassung der Formulare.

Um diese externe Erfassung zu ermöglichen kommt dann oft eine Excel-Liste als Transfermethode zum Einsatz. So müssen die externen Sachbearbeiter nichts Neues lernen und im Zielsystem wird eine kleine Importfunktion hinzugefügt. Soweit ist dies ebenfalls noch kein Problem. Doch was soll nun ins Feld „Erstellt“ geschrieben werden? Das Datum an dem die Daten importiert wurden oder das Eingangsdatum?

Aus fachlicher Sicht muss das Eingangsdatum gesetzt werden, da sich zwischen dem Eingang und dem Import Preise verändert oder Fristen abgelaufen sein könnten. Aus technischer Sicht wird das Formular mit dem Import erstellt.

Das Problem ergibt sich sobald beide Sichten „ihr“ Datum benötigen. Das technische Erstelldatum könnte beispielsweise für einen Report zur internen Kostenverrechnung dienen. Wird dieser Report nach Eingang aber vor dem Import der Formulare ausgeführt stimmen die Werte nach dem Import nicht mehr mit dem Datenbestand in der Applikation überein. Die importierten Formulare fehlen im Report, werden daher nicht verrechnet und Ende Jahr gilt es zu klären woher die Differenz kommt.

 

Ursachen

Bei den Fällen die mir bekannt sind war die Ursache oft eine verfrühte Optimierung oder der krampfhafte Versuch Diskplatz zu sparen. Weder der zusätzliche Speicherplatz noch der Aufwand ein Feld mehr anzulegen hätte man bemerkt. Im Gegensatz zu all dem Aufwand zum Aufspüren der fehlerhaften Auswertungen.

Bitte beachten: DRY (Don’t repeat yourself) gilt nur wenn es sich wirklich um die gleichen Dinge handelt. Andernfalls ist dies keine Repetition sondern erfüllt einen anderen (unabhängigen) Zweck.

 

Wie verhindern?

Im obigen Beispiel hätte man spätestens als die Importfunktion erstellt wurde die Datenfelder trennen müssen. Allerdings denkt in so einem Moment niemand an solche Zusatzaufgaben. Und nur um Daten genauer abzulegen will niemand all die Oberflächen und Reports anpassen.

Daher bin ich mittlerweile der Meinung dass bei den ersten Anzeichen einer fachlichen Verwendung der technischen Daten die Alarmglocken läuten müssen. Fängt man an bei einzelnen Objekten technische Felder einzublenden ist dies ein deutliches Zeichen das hier ein fachliches Feld fehlt. Der Aufwand dies jetzt gleich sauber zu lösen ist geringer als wenn man wartet bis dieses Feld überall verwendet wird. Und fehlt doch gerade die Zeit kann man immer einen entsprechenden Task eröffnen und im nächsten Sprint (mit zusätzlichen Informationen) beheben.

Dies gilt übrigens im gleichen Masse für fachliche Felder die technisch genutzt werden, auch wenn dieser Fall wohl weniger oft vorkommt.

 

Fazit

Das Single Responsibility Principle (SRP) gilt nicht nur für Klassen und Methoden, sondern auch für Daten. Bevor man für eine kleine Einsparung bei der Datenmenge anfängt Felder mehrmals zu verwenden sollte man sich über die möglichen Konsequenzen bewusst werden und darauf verzichten. Angesichts der aufwändigen Fehlersuche bezweifle ich das durch ein „eingespartes“ Feld wirklich Kosten gespart werden können.