---

Juli 2015

Band 30, Nummer 7

Visual Studio 2015 - Analyse Architektur mit Code-Karten im Visual Studio 2015

Von Blair McGlashan | Juli 2015

Verbesserung der Architektur der Anwendung ist entscheidend für den Aufbau technischer Schulden zu verhindern, und für die Aufrechterhaltung der guten Codierung Geschwindigkeit. Weiter, immer ein schnelles Verständnis der Auswirkungen einer möglichen Codeänderung ist ein wichtiger Aspekt der Entscheidung, ob die Änderung sinnvoll ist und wenn ja, welche wahrscheinlich Kosten. Beide Ziele erfordern eine Fähigkeit, die Architektur Ihrer Anwendung zu verstehen und analysieren die Abhängigkeiten es aufgetaucht. Um das erste Tor zu lösen, Sie in der Regel von oben arbeiten und drill-down. Um die zweite zu lösen, Sie in der Regel aus einem bestimmten Codeelement arbeiten und erweitern sich.

In diesem Artikel zeigen wir, wie Code-Karte, erweitert mit neuen Funktionen in Visual Studio 2015 Unternehmen, verwendet werden können:

• Die Gesamtarchitektur einer .NET Anwendung zu verstehen.
• Analysieren von Abhängigkeiten tauchte in dieser Architektur durch schrittweise in die Details zu bohren.
• Verstehen Sie und analysieren Sie die Auswirkungen einer vorgeschlagenen Änderung des Codes durch den Bau einer Abhängigkeit-Karte aus einem bestimmten Codeelement.

Wir haben zwei Beispiele zur Veranschaulichung. Für hierarchische Architektur und Bohren in haben wir die "Roslyn" Code-Basis (die .NET-Compiler-Plattform) verwendet. Wir haben dies aus zwei Gründen gewählt. Erstens ist es groß, so verstehen die Gesamtarchitektur ist nicht so einfach. (In der Tat ist es so groß, dass in der Regel musst du warten, bis ein paar Minuten von einem kalt-Start im erste Diagramm während der anfänglichen Build und die Indizierung stattfinden zu erstellen. Performance ist viel besser mit kleineren Lösungen.)

Zweitens ist Roslyn open Source, so können Sie dies leicht selbst ausprobieren. Um die Auswirkungen der vorgeschlagenen Änderung zu analysieren, haben wir einen experimentellen Prototyp von Microsoft zur Visualisierung eines Rückstands in Team Foundation Server (TFS) verwendet. Dies ist nicht öffentlich verfügbar, aber wir auch ein Codeelement in Roslyn-Codebasis, die Sie, in ähnlicher Weise ausprobieren können zu identifizieren, obwohl der Grund dafür in diesem Fall also weniger klar ist.

Wir verwendeten die RTM-Version von Visual Studio 2015 Enterprise Edition werden von heruntergeladen kann bit.ly/1JbLA4S.

Verstehen der Gesamtarchitektur

Unser Ausgangspunkt war die Roslyn-Lösung im Visual Studioeröffnet, und bereits gebaut. Um dorthin zu gelangen, wir geklont das Git-Repository von https://github.com/dotnet/roslyn, der Git Klonen Erfahrung auf der Connect-Registerkarte des Fensters Team Explorer Visual StudioStudio verwenden und dann öffnete der RoslynLight.sln-Lösung, die automatisch beim Öffnen des geklonten Repositorys gefunden wurde. Dann liefen wir das src\.nuget\NuGetRestore.ps1-Skript über die Eingabeaufforderung Entwickler für Visual Studio 2015 wieder die NuGet Pakete benötigt, um die Projektmappe zu erstellen. (Ausführung von Windows PowerShell -Skripts ist standardmäßig deaktiviert. Aktivieren der Skriptausführung erfordert eine erhöhte Eingabeaufforderung. Wenn Sie nicht vertraut mit Windows PowerShellsind, möglicherweise finden Sie es einfacher das Skript ausführen, indem mit der rechten Maustaste und wählen Sie mit PowerShell ausführen aus dem Windows-Explorer.)

Als nächstes haben wir das xunit.runner.visualstudio NuGet Package die Lösung damit die Roslyn-Lösung, die xUnit-Tests sind, wurden von Visual Studioerkannt. Schließlich haben wir die Lösung (Dies kann einige Zeit dauern). Um ein sofortiges Verständnis der Architektur dieses Codes Basis erhalten, haben wir die generieren Code-Karte für Lösung ohne Option im Menü Architektur Gebäude gewählt. So entstand eine Karte, die in einem Diagramm die Lösung Struktur und Projekt-Referenzen werden. Insbesondere sehen die Referenzen können Sie entnehmen, wie die verschiedenen Teile der Lösung in einer Weise miteinander verknüpft sind würde Sie einfach können nicht schätzen, indem Sie sich die Lösung, und viel der Erforschung von Projektverweisen herauszufinden.

Sobald alle Binärdateien in den Code Index (im wesentlichen einer SQL-Datenbank speichern der vollständigen logischen Struktur des Codes) indiziert wurden, verwandelt sich die Karte in was Sie in sehen Abbildung 1. Die neue Karte zeigt viel reicheren Abhängigkeiten, farbcodierte Legende (Klicken Sie auf die Schaltfläche in der Symbolleiste Code Karte anzeigen), deren Dicke den Grad der Abhängigkeit zwischen den zugehörigen Komponenten spiegelt. Beispielsweise gibt eine grüne Verbindung Vererbung (und möglicherweise andere Abhängigkeiten) zwischen Klassen in die zugehörigen Projekte. Die dunkleren grün-Knoten darstellen Testprojekte.

Abbildung 1 Architektur Karte nach Indizierung

Die Filter auf der rechten Seite können verwendet werden, um verschiedene Arten von Abhängigkeit auszuschließen. Beispielsweise sollten Sie das Diagramm mit allen Testcode versteckt oder alle Links versteckt außer Vererbung und implementiert Links anzeigen. Sie könnten auch generische Knoten ausblenden und löschen alle Knoten mit referenzierten Assemblys, die die Lösung sind. Dies macht es leicht zu sehen, wo die Architektur der Produktcode Vererbungsbeziehungen Gerês (Prüfungen werden als Produktcode nicht gezählt).

Z. B. gibt Blick auf die Wurzeln der erbt aus und Implements Beziehungen Ihnen ein Gefühl für die begrifflichen Abstraktionen im Rahmen. Sie können sehen, dass der Compiler Rahmen an der Basis von allem anderen. Im Rahmen der Compiler ist der Kern auch an der Basis, aber es auch einige Klassen im Kern, die scheinen gibt, leiten Sie von den CSharp und VisualBasic-Schichten, die, vielleicht ein Hinweis ist, dass die Schichtung ist nicht ganz richtig. (Wir untersuchen weiter im nächsten Abschnitt zeigen wie.)

Sie können zoom auf Bereiche des Diagramms weiter erkunden und sogar wählen Sie einen Knoten oder Knoten (gedrückter Ctrl-Taste ermöglicht eine Mehrfachauswahl) auf ein anderes Diagramm verwenden das neue Diagramm von Auswahl-Kontextmenübefehl erkunden. Z. B. Abbildung 2 veranschaulicht das Ergebnis für die Kern- und CSharp Teilkonzerne der Compiler in den Rahmen dafür. Unten-nach-oben-Layout wurde auch auf das Ergebnis angewendet um Basistypen an der Spitze haben.

Abbildung 2 durch das Vergrößern der Vererbungshierarchie

Eine Abhängigkeit zu analysieren

Wie man deutlich, in sehen kann Abbildung 2, der Kern erbt einige Klassen von CSharp und VisualBasic, das ist ein bisschen überrascht. Werfen wir einen Blick in diese Bohren, wie weiter zu sehen, was die Anomalie verursacht. Wir begannen, indem Sie auswählen den Abhängigkeits-Link (zwischen Kern und CSharp) und zeigen einen Beitrag Links auf neue Code-Karte. Zeigt das Ergebnis Abbildung 3.

Abbildung 3 Ergebnis der Bohrungen in den Zusammenhang zwischen Kern und CSharp

Wir haben gesehen, dass eine Klasse Schuld ist und hatte zu Fragen, ob Sie tatsächlich das VBCSCompiler.exe Projekt/Montage wirklich Teil der Core-Gruppierung sein sollte. Vielleicht mussten wir die Lösung-Ordnerstruktur ausziehen es umgestalten. Doch bevor Sie diese Änderung vornehmen, wir Codezuordnung genutzt, um die möglichen Auswirkungen zu erkunden. Geht zurück auf die Landkarte, Abbildung 2, wir könnten wieder alle Link-Filter zu aktivieren, um alle Assemblys finden Sie unter und Bearbeiten des Diagramms durch Verschieben des VBCSCompiler.exe Knotens von Core CSharp, die Auswirkungen auf Abhängigkeiten zu sehen (siehe Abbildung 4). Dies erschien sicherlich Dinge bereinigen, obwohl wir dann festgestellt, dass die Roslyn.Compilers.CompilerServer.UnitTests.dll auch an der falschen Stelle zu sein schien. Exploration kann in diesem Sinne weiter. Sie können sogar neue Gruppenknoten erstellen, auf das Diagramm, eine sauberere Architektur zu produzieren, die informieren, Umgestaltung der Projektmappenordner sowie tiefer Refactorings, wie z. B. die Aufteilung von Klassen oder Schnittstellen zwischen Assemblys verwendet werden können.

Abbildung 4 Verschieben von Knoten, die Auswirkungen von potenziellen Refactorings auf Abhängigkeiten zu erkunden

Analyse der Auswirkungen der vorgeschlagenen Änderung

Sie haben gesehen, wie die Architektur und die Abhängigkeiten von einer Codebasis von oben nach unten untersucht und wie die Abhängigkeiten analysieren näher identifizieren helfen können. Sie haben gesehen, wie Codezuordnung effektiv verwendet werden kann, dazu, dass die Analyse durch schrittweise in unteren Detailebenen bohren. Jetzt werden wir zu ändern Tack und schauen wie die gleichen Funktionen verwendet werden können, um Abhängigkeiten mit einem Bottom-up-Ansatz, erkunden ein Codeelement ab. Insbesondere werden wir den Satz von Abhängigkeiten zu identifizieren, die verweisen auf das Codeelement und kann beeinflusst werden, wenn das Code-Element geändert wird.

Unser Beispiel zeigt Code aus einer Experimenteller Prototyp von Microsoft, die zum Visualisieren und Änderungen an ein Rückstand im Visual Studio Online TFS mit hierarchischen Kanban-Mainboards verwendet wird. Wir wollten in diesem Beispiel fügen Sie die Möglichkeit, den Titel einer Arbeitsaufgabe direkt über der Karte zu ändern, erfordert das Hinzufügen eines neuen Enumerationsliteral in die ChangedProperty-Enumeration. (Wenn Sie diese mit Enum in Roslyn-Codebasis versuchen möchten, können Sie Microsoft.CodeAnalysis.LocationKind verwenden.) Zuerst wollten wir jedoch erforschen die Auswirkungen dieser Änderung zu machen, damit wir auf die Referenz-CodeLens-Anzeige geklickt und dann auf die Show am Code-Karte Link geklickt.

Sehen Sie das Ergebnis in Abbildung 5, die alle Methoden präsentiert und andere Klassenmember diesen Verweis das Changed­Eigenschaft Enum in irgendeiner Weise. Dieses Diagramm zeigt die Mitglieder im architektonischen Kontext; Das heißt, gruppiert nach Klasse, Namespace, Montage und Projektmappenordner. Dann verwendet die Filter Lösung Ordner und Assemblys zu beseitigen und das Layout in einem Links-nach-rechts-Format geändert.

Abbildung 5 The Reference Abhängigkeit Karte nach versteckt Lösung Ordner und Assemblys und Verlegehilfe von links nach rechts

Diese Karte kann nun verwendet werden, um alle Bereiche des Codes zu erkunden, die von dieser Änderung betroffen sein könnte. Nicht nur können Sie die Karte zum Navigieren im Codes — Doppel-Klick auf einen Knoten bringt Sie an der richtigen Stelle im Code – Sie können es auch verwenden, um Muster im Design zu sehen. So, wie Abbildung 5 zeigt, Sie können sofort sehen, dass die Methode SortAndReparent in Klassen von der StoryMaps.ViewModel-Namespace wird und eine Schnellprüfung des Codes einer dieser Klassen enthüllt, dass keine Codeänderung erforderlich ist. Jedoch beim Betrachten der Process-Methode in der WorkItemsWriter-Klasse können Sie sofort aus dem Diagramm sehen, die es enthält Unterkategorien, eine für jedes Literal in der ChangedProperty-Enumeration Aufrufe. Hinzufügen einer neuen Literal dürfte bedeuten, dass eine neue Teilprozess Methode benötigt werden. Inspektion des Codes bestätigt diese s­­­­­­­­Uspicion.

Wie Sie diesen Prozess durchlaufen haben, können Sie machen, Knoten grün, rot oder eine andere Farbe an, ob Folgemaßnahmen erforderlich ist (verwenden Sie das Untermenü "Bearbeiten" des Kontextmenüs | Flag für Follow-up), ebenso wie das Diagramm mit detaillierter Kommentare hinzu (siehe Abbildung 6).

Abbildung 6 kommentierte Verweise Abhängigkeit anzeigen

Nachbereitung

Verstehen die Architektur Ihrer Anwendung ist wichtig, und also ist die Kenntnis der Auswirkungen jeder potenzielle Code-Änderung.

In diesem Artikel haben wir gezeigt, wie mit Code-Karte, erweitert mit neuen Funktionen in Visual Studio 2015, verstehen und analysieren die Gesamtarchitektur Ihrer .NET-APP und Abhängigkeiten auf hoher Ebene untersuchen. Zu diesen Funktionen gehören:

• Ein viel-verbesserte auf oberster Ebene Diagramm generiert aus einer Lösung, die Lösung Ordner verwendet, um eine erste Gruppierung von Knoten und Stile Projektknoten entsprechend ihrem Typ bereitzustellen.
• Eine Auswahl auf eine vorhandene Zuordnung ordnet die Möglichkeit, den neuen Code zu erstellen.
• Knoten und Link filtern, insbesondere die Möglichkeit, Tests und verschiedene Arten von Links herauszufiltern.

Wir dann zeigte wie Bohren in eine Abhängigkeits-Link, verbessert in Visual Studio 2015 zur Inanspruchnahme von Link-Filter können schnell ans Licht die Ursache für eine unerwünschte Abhängigkeit, bis hin zu der Codezeile, in dem die Abhängigkeit wird eingeführt.

Schließlich haben wir gezeigt, wie Sie ergreifen können, einen Bottom-up-Ansatz mit Code-Karten, die Auswirkungen der vorgeschlagenen Codeänderung erforschen die Abhängigkeit Karte aus CodeLens der Referenzkennzeichen aus einem bestimmten Codeelement erstellt, und dann mit Kommentaren und Flaggen im Diagramm Aufzeichnen der Ergebnisse der Analyse der Auswirkungen von der Änderung zu offenbaren.

---

Stuart Kent Gruppe Programmmanager bei Microsoft verantwortlich für Entwickler Erfahrungen im Visual Studio und Visual Studio Online, konzentrierte sich auf die Steuerung technischer Schulden und Codesharing und Zusammenarbeit ist. Dazu gehören die Architektur Analyse-Tools, Aspekte der CodeLens und Code-Suche.

Jean-Marc Prieur ist leitender Programmmanager bei Microsoft Vorstellungsvermögen und fahren die Lieferung von Erfahrungen im Visual Studio und Visual Studio Online Steuerung technischen Schulden, einschließlich Architektur-Analyse-Tools.

Blair McGlashan ist ein engineering-Manager führt ein Team mit Sitz in Cambridge, Großbritannien, liefert Erfahrungen konzentriert sich auf technische Schulden, einschließlich Architektur-Analysetools.