Captain, da kommt was auf uns zu!

Visual Studio 2014 als Paradigmenwechsel in der Softwareentwicklung
Kommentare

Eine IDE wie Visual Studio 2014 wird vom Produkthersteller (weiter-)entwickelt und anschließend von den Nutzern weltweit zur Realisierung ihrer eigenen Softwareprojekte verwendet. Dabei werden Schwächen oder Verbesserungspotenziale festgestellt, die dann den Weg über das Anforderungsmanagement bis hin zum Releasemanagement gehen, um in der Folgeversion der Entwicklungsplattform berücksichtigt zu werden. So funktioniert bislang – sehr vereinfacht formuliert – der Kreislauf zwischen der Nutzung der aktuellen und der Entwicklung der nächsten IDE-Version.

Dieses klassische Weltbild zwischen der Realisierung und der Anwendung von Entwicklungsumgebungen mutet wie eine Einbahnstraße vom Hersteller zum Anwender an. In unserer heutigen von Teamwork, Globalisierung und Informationstransparenz geprägten Zeit wirkt dies jedoch wie ein Anachronismus – nicht mehr zum Zeitgeist passend. Microsoft scheint dies erkannt zu haben und möchte dementsprechend Ende 2014 nicht nur eine weitere Visual-Studio-Version mit einigen neuen Features vorstellen, sondern einen grundlegenden Paradigmenwechsel einläuten. Das erfolgt unter dem Vorzeichen der „Microsoft Open Technologies“ und dem Roslyn-Projekt: Anstatt den Compiler als Black Box zu behandeln, bekommt nun jeder Entwickler die Möglichkeit, die darin benutzten Technologien im Detail zu verstehen. Dies könnte das allgemeine Verständnis der Zusammenarbeit zwischen Auftraggeber und Auftragnehmer im Bereich der Softwareentwicklung grundlegend verändern.

Auf der Build 2014 im April wurden die Entwicklungsfortschritte von Visual Studio 2014 anhand der Community-Technical-Preview erläutert. Im Rahmen dieser Veranstaltung wurde außerdem der Quellcode des Roslyn-Projekts freigegeben. Dies geschah durch den symbolischen Klick auf einen Websitebutton und wirkte geradezu unscheinbar in Anbetracht seiner tatsächlichen Bedeutung: Unter roslyn.codeplex.com steht nun der Code für die .NET-Compiler-Plattform bereit. Mit dieser einfachen Handlung hat Microsoft seine Technologie offengelegt: Die Roslyn-Plattform gibt nun tiefe Einblicke in den Compiler für die Programmiersprachen C# und Visual Basic. Es stellt diese Informationen über eine Programmierschnittstelle zur Verfügung und erlaubt so die bidirektionale Kommunikation mit dem Compiler. Die Einbahnstraße gibt es nicht mehr.

Roslyn selbst ist jedoch nicht neu: Bereits zu Zeiten der Visual-Studio-2012-Entwicklung machte der Begriff in der Entwicklerszene die Runde: Hinter Microsofts Roslyn-Projekt steht die Grundidee, den Compiler als Dienst zu betrachten, der alle Schritte von der Quelltextanalyse bis zum Generieren des .NET-Bytecode (CIL-Code) ausführt. Jede einzelne Phase ist dabei separat steuerbar, sodass man jederzeit entsprechende Informationen abrufen kann. Ziel ist, die Analyse des Quellcodes und der Programmsemantik per .NET-APIs zur Verfügung zu stellen. In den zurückliegenden Jahren konnte man Roslyn nur als eine Plattform im frühen Entwicklungsstadium ansehen, wobei die Sprachenunterstützung sehr begrenzt war. Nun wird die Plattform aber in das offizielle Visual Studio integriert, der vorhandene Compiler wird somit ersetzt und die unterstützten Sprachen nehmen zu: Insgesamt betrachtet ein Quantensprung für Entwickler.

Die auf Roslyn basierenden Compiler sind als klassische Kommandozeilenprogramme und per API aufrufbar. Dabei sind sie in sich selbst geschrieben und nicht wie früher in C++.

APIs stellen den Zugriff auf die Dienste her

Für alle Grundschritte stellt Roslyn APIs bereit: für die syntaktische bzw. lexikalische Analyse des Quelltexts, die semantische Analyse der abstrakten Syntaxbäume (AST) sowie schließlich für die Übersetzung in den CIL-Code und die Erzeugung des nativen Codes für die Ausführung.

Damit lässt sich eine Vielzahl von internen Projekten verwirklichen, denn bei komplexen Programmen braucht nicht nur der Compiler detaillierte Kenntnisse über den Code, sondern auch der Debugger für die Codeflussanalyse und die Entwicklungsumgebung, beispielsweise für das Refaktorieren des Quelltexts. Auch weitere Tools profitieren davon, so etwa das Analysetool PreSharp, das Microsoft intern zur statischen Fehleranalyse von Quelltextdateien verwendet.

Aus statischen Sprachen wie C# macht die Roslyn-Architektur dynamische Sprachen, die zur Laufzeit Code erzeugen und ausführen können. Damit entfällt der Nachteil einer Compilersprache gegenüber interpretierten Skriptsprachen und der Quelltext ist ohne weitere Verarbeitungsschritte sofort lauffähig. Der Vorteil des Compilers bleibt indes bestehen: Eine Reihe an Prüfungen stellt sicher, dass das Programm formal fehlerfrei ist.

Neue Möglichkeiten für Softwareentwickler und Toolhersteller

Mit der Open-Source-Bereitstellung des Roslyn-Projekts öffnet sich das Tor zu einer neuen Welt: „software development at the next level“, Verbindung von Fremdprodukten mit dem Compiler, Offenlegung der Technologien. Für das betreffende Microsoft-Entwicklungsteam muss dieser Prozess demnach, wenn man verschiedenen Blogs Glauben schenken darf, eine geradezu nervenaufreibende Zerreißprobe bedeutet haben, die im Rahmen der R&D-Aufgaben in den letzten zwölf Monaten zusätzliche Energie abverlangte. Zum einen natürlich der Geheimhaltung wegen, zum anderen aber auch aufgrund der zahlreichen zu realisierenden Möglichkeiten in Kombination mit einem ambitionierten Zeitplan.

Eigene Programme lassen sich zudem um eine Skriptsprache für Makrofunktionen erweitern. Deshalb dürfte Roslyn gerade für Toolhersteller interessant sein, die Erweiterungen für Visual Studio anbieten möchten. Denkbar wären beispielsweise Werkzeuge zur Ressourcen- und Performanceanalyse, Dotfuscatoren, Source-Beautifier und Tools zur Integration von Trace-Ausgaben.

Funktionen und Aufbau von Roslyn

Viele Entwicklungsfeatures wie IntelliSense, Refactoring und CodeLens setzen jetzt auf dem .NET-Compiler-Framework Roslyn (Abb. 1) auf. Durch die verbesserte modulare Struktur können Drittsoftwarehersteller oder auch Entwicklungsteams ihre eigenen Erweiterungen erstellen.

Abb. 1: Übersicht zu Roslyn

Roslyn bietet dazu APIs für den Bereich der Compiler mit den Unterbereichen Diagnostic und Scripting, aber auch für die Bereiche der Workspaces und Features an. Das Compiler-API hängt nicht von der IDE ab, weshalb damit erstellte Software kein installiertes Visual Studio benötigt. Über das Workspace-API kann auf die Funktionen der IDE zugegriffen werden. Das Feature-API stellt spezielle Funktionen zur Unterstützung professioneller Softwareentwicklung zur Verfügung.

1. Compiler: In seiner Vorgehensweise unterscheidet sich Roslyn nicht von einem klassischen Compiler, denn auch er basiert auf einem Scanner zum Zerlegen des Quelltexts und einem Parser zur Verarbeitung der Programmstruktur. Ungewöhnlich ist nur, dass dabei viele Zusatzinformationen erhalten bleiben, die andere Compiler während der Verarbeitung verwerfen. Compiler merken sich normalerweise nur den Namen und die Zeilennummer der Quelltextdatei, um Fehler auszugeben. Roslyn hingegen behält bei der Analyse des Sourcecodes alle Informationen, um aus den internen Strukturen heraus wieder den Originalquelltext zu rekonstruieren. Dabei finden Syntaxbäume Verwendung (Klasse SyntaxTree), die alle Informationen aus dem Quelltext aufnehmen, selbst Kommentare und Whitespace, von Roslyn als „Trivia“ bezeichnet. Praktisch ist, dass sich Syntaxbäume selbst dann erzeugen lassen, wenn der Quelltext syntaktisch nicht fehlerfrei ist. Es gibt jeweils ein API für die C#- und eines für die Visual-Basic-Programmiersprache.

1.1 Diagnostic: Der Compiler kann eine Reihe von Diagnosen über Syntax, Semantik und eindeutige Zuordnungen vornehmen und hierbei verschiedene Fehler und Warnungen ausgeben. Die Compiler-API-Schicht erlaubt über ihre erweiterbare Schnittstelle benutzerdefinierte Analysen, wie z. B. Anforderungen aus der Softwarepolitik oder der unternehmens- oder projektbezogenen Engineering Guidelines – zu unterstützen und diese per Plug-in-Technologie in den Compilerprozess zu integrieren. Tools wie StyleCop oder FxCop leisten entsprechende Analysen entlang des Kompiliervorgangs. So können auch noch während des Builds Codeverbesserungen vorgenommen werden, wodurch sich die Anzahl der notwendigen Optimierungszyklen innerhalb des Software-Lifecycles reduzieren lässt.

1.2 Scripting: Die Verarbeitung von Quelltext als abstrakte Syntaxbäume lässt sich in etwa mit einer XML-Verarbeitung vergleichen. Dabei ist die Anwendung der APIs einfach. Um einen Syntaxbaum zu untersuchen, kommt die Klasse SyntaxWalker zum Einsatz, sozusagen als Iterator über die Baumstruktur. Zum Bearbeiten existiert die Klasse SyntaxRewriter, die Änderungen ausführt und daraus wieder Quelltext produziert – vergleichbar mit dem Original inklusive aller Kommentare. Spannend ist das semantische Modell (Klasse SemanticModel). Hiermit lassen sich alle Deklarationen, die Typen von Variablen oder die Gültigkeitsbereiche ermitteln; mit dem API für „Control and Data Flow Analysis“ lässt sich die Ablaufstruktur eines Programms bestimmen – beispielsweise sieht man, an welchen Stellen eine Methode mit Return verlassen wird. Wenn im Quelltext mehrfach die Variable i steht, muss es sich nicht um dieselbe Variable handeln, sie könnte auch in unterschiedlichen Gültigkeitsbereichen vorkommen. Das ist mit einer rein lexikalischen Analyse nicht erkennbar, ebenso wenig wie unbenutzte Variablen oder solche mit Zuweisungen von ausschließlich konstanten Werten zu finden sind. Hier unterscheidet sich Roslyn von der aus .NET bekannten Reflection, die auf der Ebene kompilierter Elemente (Assemblies) arbeitet. Während die Reflection in einer eingeschränkten Sichtweise nur den CIL-Code untersuchen kann und damit zur Laufzeit Informationen beispielsweise über Klassen und Typen von Rückgabewerten liefert, stellt Roslyn die Zusammenhänge zum ursprünglichen Quelltext her und ist damit deutlich flexibler.

2. Workspaces: Im Gegensatz zum Compiler, wo sich Informationen lediglich abrufen lassen, kann man mit Roslyn die Visual-Studio-Oberfläche erweitern und um Werkzeuge anreichern. Diese könnten beispielsweise Auskunft über Programmelemente geben oder helfen, den Quelltext neu zu strukturieren.

3. Features: Über das Feature-API lassen sich besondere Funktionalitäten zur professionellen Softwareentwicklung ansprechen. Dazu gehören unter anderem die neue Refactoring-Funktion und die statische Codeanalyse.

Aufmacherbild: businessman standing in ocean and looking through a telescope von Shutterstock / Urheberrecht: Peshkova

Beispiele für mögliche Erweiterungen auf Basis von Roslyn

Ich habe bereits am Anfang dieses Kommentars angedeutet, dass es bei Visual Studio 2014 nicht einfach nur um eine neue Version geht. VS 2014 hat es in sich, da durch den Wechsel zur Open Technology neue Denkweisen vom Anwender verlangt werden, sofern er die neuen Möglichkeiten nutzen möchte. Nachfolgend möchte ich Ihnen einige der möglichen Entwicklungspotenziale vorstellen.

Nach Aussagen von Microsoft ist CodeLens für Visual Studio 2013 das gefragteste Feature. Dies ist nicht verwunderlich, werden dem Softwareentwickler doch mit diesem Werkzeug wichtige Informationen direkt im Editor eingeblendet, z. B. die Anzahl der Referenzen zu einer Funktion, Daten zum Changemanagement oder Testergebnisse über die Codequalität. Durch das offene Framework können nun eigene Erweiterungen geschrieben und an CodeLens „angedockt“ werden. Beispielsweise könnte eine solche Erweiterung feststellen, ob es Änderungen im Versionsmanagementsystem gibt, die Auswirkungen auf die betreffende Methode haben könnten. Dadurch könnten Merge-Konflikte vermieden werden, noch ehe sie auftreten.

Es weiteres wichtiges Visual-Studio-Tool ist sicherlich das Refactoring, dessen Funktionen in letzter Zeit erheblich ausgedehnt wurden. Mit diesem Werkzeug kann man nun über die Definition mehrerer Suchkriterien mit unterschiedlicher semantischer Bedeutung auch nach Code-Patterns suchen (Abb. 2). Im Rahmen seiner Codeanalyse berücksichtig das Tool auch die Semantik.

Abb. 2: Test der neuen Refactoring-Funktion

Nun wieder zurück zum Anpassungsthema: Refactoring stellt ja immer eine kritische, aber notwendige Entwickleraufgabe dar, um den Code wartbar zu halten. Obschon das Vorgehen im Prinzip immer das gleiche, gibt es von Unternehmen zu Unternehmen oder gar in verschiedenen Projekten stets Unterschiede in der Durchführung. Dies liegt unter anderem an den unterschiedlichen Engineering-Guidelines, die natürlich – bei vollständiger Berücksichtigung im Rahmen der Entwicklung – die Codestruktur beeinflussen. Bislang war es die Aufgabe des Entwicklers, die konkrete Herangehensweise im Refactoring mit den geltenden Regeln und Konventionen im Projekt abzustimmen. Über das entsprechende API (Features) lässt sich das Refactoring nun so anpassen, dass es auch die jeweiligen Projektspezifika besser berücksichtigt und den Entwickler somit bei der Codeoptimierung und -restrukturierung besser unterstützen kann.

ASP.NET VNext: Bessere Unterstützung in der Cloud

Visual Studio 2014 wird ASP.NET vNext beinhalten. Bereits vor einigen Wochen wurde das neue .NET Framework angekündigt, das neben Server- auch Cloud-Anwendungen unterstützen wird. Die Visual Studio „14“ CTP gibt erste Einblicke in das neue Framework. Zur Anlegung von Webanwendungsprojekten stehen entsprechende ASP.NET-vNext-Templates zur Verfügung (Abb. 3).

Abb. 3: Auswahlbildschirm zur Erstellung eines neuen Projekts

ASP.NET vNext habe ich mir etwas näher angeschaut: Der Code lässt sich rasch kompilieren und das fertige Programm scheint eine gute Abarbeitungsgeschwindigkeit zu zeigen, soweit ein erster Blick diese Aussage erlaubt. Außerdem bringt das Framework einige Verbesserungen für Cloud- und On-Premises-Szenarien mit. Durch eine Verschlankung des Frameworks können Anwendungen schneller gestartet werden und benötigen darüber hinaus weniger Hauptspeicher. Diese Verbesserungen im Systemverhalten sind für jeden Anwender sofort spürbar.

Neben vNext werden aktuell weitere neue .NET-Technologien für Visual Studio 2014 realisiert. Hierzu zählen .NET Native für den Windows-App-Store und eine neue Version des Just-in-Time-Debuggers (JIT). Den Roslyn-Compiler erwähnte ich bereits.

Visual C++

Natürlich arbeitet Microsofts Entwicklungsabteilung auch an der Weiterentwicklung der Sprache C++. In diesem Bereich wurden bislang 31 Verbesserungen beziehungsweise Spracherweiterungen umgesetzt. So unterstützt die Sprache in der Visual-Studio-„14“-CTP-Version nun beispielsweise benutzerdefinierte Literale, alignof und alignas.

Abb. 4: Roadmap zu C++

Doch die Entwicklung ist noch nicht abgeschlossen. Vielmehr zeigt die aktualisierte Roadmap zu C++, dass hier noch eine Menge Arbeit auf das betreffende Team wartet. Aktuell werden die Aufgaben in der Spalte „VS ‚14‘ CTPs“ (gelber Bereich in Abb. 4) bearbeitet.

Fazit

Die Visual Studio „14“ CTP lässt bereits erkennen, dass die Architektur der Entwicklungsumgebung umfassend erneuert wird. Es ist davon auszugehen, dass Visual Studio 2014 den Entwicklern im Vergleich zur Vorgängerversion nicht nur neue Funktionen anbietet, sondern eine grundlegende neue Entwicklungsphilosophie präsentiert. Dies hat auch Auswirkungen auf andere Produkte. So wird wahrscheinlich auch der Team Foundation Server in der Version 2014 in einigen Bereichen über eine grundlegend neue Architektur verfügen, um die neuen Visual-Studio-Features umfassend unterstützen zu können.

Man sollte sich im Hinblick auf Visual Studio 2014 und TFS 2014 auf weitere Überraschungen einstellen. Auf jeden Fall ist es ratsam, sich mit der neuen Microsoft-Philosophie „Open Technology“ auseinanderzusetzen. Setzen Entwickler die neu gewonnenen Stärken der zukünftigen Version erfolgreich in eigene Projekte um, können dadurch gänzlich neue Märkte erschlossen werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -