Im ersten Teil dieser Serie haben wir beschrieben, warum die Arbeit mit großen Solutions schwierig ist. Ein wesentlicher Grund ist, dass der Überblick schnell leidet, wenn die Anzahl der Projekte zu groß wird. Dieser Eintrag beschreibt, wie Sie die Übersichtlichkeit verbessern und effizient in einer solchen Solution arbeiten können.
In professionellen Softwareprojekten ist es unerlässlich, durch eine durchdachte Struktur die Basis dafür zu legen, dass spätere Erweiterungen und die Pflege der Anwendung mit möglichst geringem Aufwand erfolgen können. Das heißt natürlich nicht, dass man bereits am Anfang alles wissen muss und eine detaillierte Architektur aufstellen kann, die die nächsten Dekaden übersteht.
Gerade im agilen Umfeld ist der „Big design up front“-Ansatz ja berechtigterweise verpönt. Dass man dies nicht mehr machen will, heißt natürlich nicht, dass man ins andere Extrem verfällt und am besten ohne jede Struktur arbeitet. Vielmehr gilt es, in jedem Entwicklungsschritt das Architekturmodell soweit fortzuentwickeln, dass es die aktuellen Anforderungen stützt und später einfach geändert oder erweitert werden kann.
Das beste Architekturmodell nützt natürlich nur dann etwas, wenn die Leitlinien, die es setzt, auch Niederschlag in die Umsetzung finden. Gerade in großen Solutions dient das Architekturmodell so als Landkarte, die dabei hilft, die einzelnen Projekte zuzuordnen und sich schneller zurecht zu finden.
Wichtig ist, dass jedes Projekt in der Visual Studio Solution nur zu einer Komponente des Architekturmodells gehört. Andersherum kann eine Komponente des Architekturmodells natürlich auf mehrere Projekte verteilt sein. Aus der Namensgebung der Projekte sollte die entsprechende Komponente des Architekturmodells auf den ersten Blick hervorgehen. Auch sollte ein konsistentes Schema bei der Namensgebung verwendet werden, z.B. nach dem Muster „Unternehmen.Projekt.Komponente.Bereich“. Dieser sollte möglichst dem Namen der erstellten Datei und dem Root-Namespace entsprechen.
Insbesondere wenn man größere Mengen fremden Codes überblicken will, ist es sehr hilfreich, wenn man die Struktur der Solution grafisch darstellen kann. Das Visual Studio 2015 bringt mit Code Maps die Möglichkeit mit, die Abhängigkeiten in einer Solution zu visualisieren (zur Erstellung ist die Enterprise Edition notwendig, zum Lesen genügt die Professional Edition).
Auch in früheren Versionen des Visual Studios waren vergleichbare Tools enthalten, allerdings erst ab der Ultimate Edition. Microsoft hat die Erstellung von Dependency Graphs jedoch in einer eigenen Visual Studio-Erweiterung namens Solution Dependency Viewer für das Visual Studio 2013 kostenlos verfügbar gemacht.
Die einfache Navigation durch den Code während der Entwicklungsarbeit stand in den letzten Visual Studio Versionen immer wieder im Fokus.
So wurde die Solution-Ansicht deutlich verbessert und durch neue Features erweitert. Durch Search Solution Explorer können die Dateien und die enthaltenen Codebestandteile wie z.B. Typen und deren Members nach einem Begriff durchsucht werden. Außerdem ist es möglich, durch einen Rechtsklick auf einen Codebestandteil verknüpfte Bestandteile zu erreichen wie z.B. die Aufrufer einer Methode.
Besonders wertvoll sind auch Befehle, die im Kontextmenü des Codefensters angeboten werden wie z.B.
Diese Möglichkeiten wurden mit dem Visual Studio 2013 in der Ultimate Edition durch CodeLens ausgebaut. Seit der Version 2015 ist CodeLens ab der Professional-Edition verfügbar.
In diesem Teil der Serie haben wir Tools und Vorgehensweisen gezeigt, die dabei helfen, den Überblick über eine Solution zu gewinnen. Im nächsten Teil wird es darum gehen, wie die Struktur einer Solution verbessert werden kann, um die Arbeit möglichst einfach zu gestalten.
Basierend auf unserer langjährigen Erfahrung im Developer Coaching haben wir folgendes Programm für Sie zusammengestellt:
.NET-Projekte durch bewährte Vorgehensweisen und stabile Strukturen erfolgreich meistern