Wirbel um Visual Studio 2010: über C# 4.0 und agile Methoden im Team Foundation Server

Inhaltsverzeichnis

Mit Visual Studio 2010 und .NET 4.0 halten auch eine neue Version von C# und die Unterstützung agiler Methoden durch den Team Foundation Server Einzug in die Programmierwelt. Was auf den ersten Blick löblich erscheint, mag für den einen oder anderen Entwickler aber nicht umfassend genug umgesetzt sein.

In jeder C#-Version hat Microsoft einen Schwerpunkt gesetzt: War das Ziel in C# 1.0 eine konsistent objektorientierte Sprache, stand die Version 2.0 im Zeichen generischer Datentypen. Besonders auffällig war die Fokussierung auf einen Aspekt in C# 3.0: Mit Ausnahme der automatisch implementierten Eigenschaften hat wohl kein einziges Sprachmerkmal Einzug in C# 3.0 gehalten, das nicht eine notwendige Vorbedingung für LINQ darstellt.

Im Rahmen von .NET 4.0 beschert Microsoft der Entwicklergemeinde nun C# 4.0. Die neue Version setzt den Fokus auf eine verbesserte Interoperabilität zu funktionalen und dynamischen Sprachen sowie eine überarbeitete Kompatibilität zu COM. Vergleicht man sie mit den Vorgängern, fällt auf, dass sich die Zahl der Neuerungen in Grenzen hält. Lediglich vier neue Funktionen respektive Sprachmerkmale bietet die Sprache, nämlich erstens optionale sowie zweitens benannte Parameter, drittens dynamische Datentypen und schließlich Ko- beziehungsweise Kontravarianz für generische Datentypen.

Optionale und benannte Parameter

Optionale Parameter ermöglichen es, Parameter einer Methode mit Standardwerten zu versehen und die Angabe der jeweiligen Parameter dadurch als optional zu kennzeichnen: Wird der Parameter – ganz klassisch – explizit angegeben, verwendet man den entsprechenden Wert; wenn nicht, nutzt man implizit den in der Methodendefinition angegebenen Standardwert.

Das Sprachmerkmal wirkt auf den ersten Blick ausgesprochen nützlich, entfällt damit die Notwendigkeit, unterschiedliche Varianten einer Methode aufwendig überladen zu müssen. Da zudem die Syntax für den Aufrufer beim Verwenden optionaler Parameter der Syntax einer überladenen Methode entspricht, scheint die Welt in Ordnung zu sein – bis man feststellt, dass optionale Parameter eine andere Semantik aufweisen als überladene Methoden.

In der Praxis sollte der Entwickler optionale Parameter daher nur im Rahmen der COM-Interoperabilität verwenden, für alle übrigen Fälle sind sie in der Regel untauglich. Ähnlich verhält es sich mit benannten Parametern: Da sie sich nur in Kombination mit optionalen Parametern sinnvoll einsetzen lassen, erübrigt sich ihr regulärer Einsatz in der Praxis.

Trotz der Mängel für den Alltagsgebrauch stellen beide Sprachmerkmale bei der Verwendung von COM eine drastische Vereinfachung dar. Wer beispielsweise jemals Microsoft Office mit den Visual Studio Tools für Office (VSTO) anbinden musste, kennt das Problem der zahlreichen "ref missing"-Parameter und wird die Möglichkeit, nur die tatsächlich benötigten Parameter angeben zu können, schätzen.

Dynamische Datentypen

Dynamische Datentypen – und hierbei insbesondere die Verwendung des Schlüsselworts dynamic – sind ein weiteres Sprachmerkmal, das auf den ersten Blick zwar ausgesprochen hilfreich erscheint, dessen Alltagstauglichkeit bei näherem Hinsehen jedoch deutliche Fragen aufwirft. Die Idee hinter dynamischen Datentypen ist, Referenzen deklarieren zu können, deren Datentyp sich erst zur Laufzeit ergibt – und der sich gegebenenfalls sogar während der Ausführung ändern kann.

Erforderlich ist das Sprachmerkmal für die Integration von C# mit dynamischen und funktionalen Sprachen: Es ist dort beispielsweise möglich, eine Methode zu definieren, die – abhängig vom Kontext – einen Int32- oder einen DateTime-Typ zurückgibt. Um die Rückgabewerte solcher Methoden in C# überhaupt verarbeiten zu können, müsste entweder auf den Datentyp object und Reflection oder auf dynamische Datentypen zurückgegriffen werden.

Im Kern arbeiten dynamische Datentypen in C# 4.0 ebenfalls mit object und Reflection – sie bieten lediglich einen einfachen und komfortablen Wrapper, stellen letztlich also "syntactic sugar" dar. Daraus folgt, dass alle Nachteile, die beim Verwenden einer Instanz mit Reflection bestehen, auch beim Einsatz von dynamischen Datentypen auftreten – von Syntaxfehlern bis hin zur geringen Performance.

Daher sollte man dynamische Datentypen nur einsetzen, wenn keine andere Lösung zur Wahl steht und ansonsten auf den Datentyp object und Reflection zurückgreifen. Durch die einfache Nutzbarkeit der bislang genannten Sprachmerkmale ist allerdings zu erwarten, dass sie sich in größerem Stil verbreiten werden.

Ko- und Kontravarianz von generischen Datentypen

Das vierte Sprachmerkmal stellt eine Ausnahme dar – denn die Sprachentwickler haben es weder für die Sprach- noch für die COM-Interoperabilität eingeführt, sondern es stellt eine von vielen Programmierern schmerzlich vermisste Funktion zur Verfügung: die Ko- und Kontravarianz von generischen Datentypen.

Obwohl der Datentyp string in .NET von object abgeleitet und somit in diesen Typ konvertierbar ist, gilt das Gleiche nicht für generische Datentypen: Eine List<string> erbt nicht von
List<object> und ist auch nicht direkt in eine solche konvertierbar – das galt bis C# 3.0.

Mit C# 4.0 führt Microsoft diese Kompatibilität ein – allerdings nicht pauschal für alle generischen Datentypen, sondern nur für generische Schnittstellen und Delegaten, wobei IEnumerable<T> wohl der häufigste Anwendungsfall sein dürfte. Auch bei der Implementierung eigener generischer Datentypen lässt sich die Option, sie zu konvertieren, explizit freischalten, wobei sogar zwischen Lese- und Schreibzugriffen zu unterscheiden ist.

Da das Sprachmerkmal schwieriger zu verstehen ist als die drei zuvor genannten, ist von der Annahme auszugehen, dass es nicht so viel Verbreitung erreichen wird wie die anderen – obwohl es von seiner Alltagstauglichkeit her deutlich geeigneter für eine weite Verbreitung wäre.

Insgesamt hinterlässt C# 4.0 gemischte Gefühle: So schön die Neuerungen einerseits für die sind, die sie für COM und die Interoperabilität mit funktionalen Sprachen nutzen können, so viel Gefahrenpotenzial bergen sie zugleich. Zudem enthält die neue Version für alle übrigen Entwickler nur Ko- und Kontravarianz von generischen Datentypen als neues Sprachmerkmal. Ob die Erweiterungen einen Sprung der Hauptversionsnummer rechtfertigen, ist daher zumindest fraglich.

TFS 2010 & Agile

TFS 2010 unterstützt agile Methoden

Der zusammen mit Visual Studio 2005 eingeführte Team Foundation Server (TFS) hat die Entwicklung in vielerlei Hinsicht vereinfacht, bietet er doch eine Integration unterschiedlicher Werkzeuge samt nahtloser Anbindung an Visual Studio und Office: Von einer stabilen Versionsverwaltung über ein ausgefeiltes Issue Tracking bis hin zum projektbezogenen SharePoint-Portal und umfassenden Reporting-Fähigkeiten ist alles Wesentliche von Haus aus vorhanden.

Einzige Ausnahme war bislang die Unterstützung für agile Methoden – in der Hinsicht hat auch die Aktualisierung auf TFS 2008 keine Besserung gebracht: Keines der agilen Rahmenwerke – von Extreme Programming (XP) über Scrum und Feature Driven Development (FDD) bis hin zu Crystal – hat Unterstützung erfahren.

Das ändert sich nun mit Visual Studio Team System (VSTS) 2010: Erstmals liefert Microsoft eine Prozessvorlage für die agile Softwareentwicklung mit, die entsprechende Arbeitsaufgabentypen, Abfragen und Berichte enthält. Derzeit enthält die Prozessvorlage fünf Arbeitsaufgabentypen, die speziell auf die agile Entwicklung zugeschnitten sind:

• Aufgabe
• Benutzergeschichte
• Fehler
• Problem
• Testfall

Außerdem ermöglicht VSTS 2010 die Integration von Excel-Arbeitsmappen, mit denen sich die agilen Artefakte Produkt- und Iterationsbacklog pflegen und mit Visual Studio respektive den zugehörigen Arbeitsaufgaben verknüpfen lassen. Die beiden Neuerungen basieren im Wesentlichen auf den Abfragemöglichkeiten von VSTS 2010.

Darüber hinaus enthält die Produktbacklog-Arbeitsmappe ein eigenes Arbeitsblatt, das eine Kapazitätsplanung auf Basis der vorherigen Iterationen ermöglicht – getreu dem agilen Prinzip des gestrigen Wetters. Zu guter Letzt gibt es in der agilen Prozessvorlage von VSTS 2010 auch Berichte, die eine agile Vorgehensweise unterstützen: Hier sind insbesondere die für Scrum typischen Burndown-Berichte zu nennen.

Die Unterstützung agiler Methoden in VSTS 2010 konzentriert sich damit im Wesentlichen auf die Verarbeitung typischer agiler Artefakte und die Projektplanung. Die Prozessvorlage und die Excel-Arbeitsmappen orientieren sich deutlich an Scrum. Auf der einen Seite ist das durchaus begrüßenswert, da Scrum eine etablierte Methode darstellt, auf der anderen Seite fehlen in VSTS 2010 aber genau die Elemente, die auch Scrum fehlen: So liefert Scrum zwar einen Projektrahmen, lässt allerdings konkrete Richtlinien für den einzelnen Entwickler vermissen, weshalb Projektteams Scrum in der Praxis häufig durch XP oder eine vergleichbare Methode ergänzen.

Insgesamt stellt VSTS 2010 mit der agilen Prozessvorlage eine geeignete Ausgangsbasis für die agile Entwicklung zur Verfügung, konzentriert sich dabei aber auf die Projektplanung und -organisation. Die Umsetzung anhand konkreter Praktiken erfolgt wie zuvor ohne zusätzliche Unterstützung – außer einer Versionsverwaltung, Issue Tracking und kontinuerlierlicher Integration bekommen Entwickler auch in VSTS 2010 noch zu wenig geboten.

Golo Roden
ist freiberuflicher Wissensvermittler und Technologieberater für .NET, Codequalität und agile Methoden. (ane)