Auf dem Weg zu C# 7: Sprachfeatures und Entwicklungsprozess

Die nächste Version der Programmiersprache C# entsteht dank Microsofts Hinwendung zur Open-Source-Entwicklung unter den Augen der Öffentlichkeit. In einem ersten Design Meeting hat das zuständige Team die Weichen für das weitere Vorgehen gestellt, auf das Programmierer aktiv Einfluss nehmen können.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen
Lesezeit: 13 Min.
Von
  • Robin Sedlaczek
Inhaltsverzeichnis

Die nächste Version der Programmiersprache C# entsteht dank Microsofts Hinwendung zur Open-Source-Entwicklung unter den Augen der Öffentlichkeit. In einem ersten Design Meeting hat das zuständige Team die Weichen für das weitere Vorgehen gestellt, auf das Programmierer aktiv Einfluss nehmen können.

Dank der neuen Offenheit von Microsoft lassen sich die Teams des Softwareanbieters nun bei ihrer Arbeit über die Schulter schauen. Doch nicht nur das, die Community ist aufgerufen, eigene Vorschläge in Form von Pull Requests in den GitHub-Repositories des Unternehmens einzureichen. Die Offenlegung des Codes und ein neuer Entwicklungsprozess mit starkem Fokus auf die Kollaboration mit der Community gewährt dabei frühzeitige Einblicke in die Arbeit von Microsoft und die Funktionen, die in seinen Techniken unterkommen sollen.

Das Projekt "Roslyn", formell als .NET Compiler Platform bezeichnet, hat vor dem Hintergrund eine hohe Bedeutung. Mit ihm legt der Softwareanbieter eine der wichtigsten Komponenten seiner Entwicklungsplattform offen: die Compiler des .NET Framework, darunter die Übersetzer für C# und VB.NET.

Der Quellcode ist dabei aber nicht das Einzige, was Microsoft offenlegt. Diskussionen und Design Meetings gehören ebenso zum offenen Entwicklungsprozess mit der Community. Am 21. Januar 2015 veröffentlichte das Team um Projekt Roslyn das Protokoll aus dem ersten Design Meeting für C# 7.

Da die Entwicklung von Open-Source-Projekten Neuland für Microsoft ist, muss zuerst ein Prozess etabliert werden, der die Weiterentwicklung des .NET Framework und der zugehören Sprachen mit zunehmender Offenheit und unter Einbezug der Community gewährleistet. Trotz scheinbar unerschöpflicher Ideen aus der Gemeinschaft muss Microsoft aber weiterhin einen gewissen Release-Zyklus und damit eine Planbarkeit sicherstellen, was nicht zuletzt für Geschäftskunden einen hohen Wert hat.

Aus dem Grund führt ein Kernteam von Microsoft die Design Meetings durch. Das Einbeziehen externer Mitarbeiter ist geplant. Die Zusammentreffen sollen via Aufzeichnung oder Live-Streams veröffentlicht werden. Protokolle werden letztlich als Issues auf GitHub zur Verfügung gestellt, um über die Plattform wiederum Feedback aus der Community sammeln zu können. Entwickler können ihre Ideen dort ebenfalls als Issues einbringen.

Um Interesse an einzelnen Ideen zu demonstrieren, lässt sich die User Voice verwenden. Ist die Nachfrage hoch genug, nimmt das Design Team die Idee in die Agenda eines Meetings auf. Eines der Teammitglieder bekommt dann die Verantwortung für den Vorschlag, sammelt Feedback, kümmert sich um das Entwurfsdokument (Proposal Document) und sorgt für entsprechenden Fortschritt zwischen den Treffen. Feature-Ideen werden mit Prototypen getestet.

Interne sowie externe Pull Requests können beim Entwurf eines neuen Features und bei der Entscheidung helfen, es in den Sprachumfang aufzunehmen. Für die finale Entscheidung behält Microsoft sich allerdings das Stimmrecht vor und somit letztlich die Oberhand. Aus dem Grund beschreibt der Softwarehersteller den Prozess nicht als demokratisch, sondern als eine "wohltätige Diktatur".

In dem im Januar durchgeführten ersten Design Meeting wurde aber nicht nur der Entwicklungsprozess diskutiert. Es ging auch um die Features kommender Sprachversionen. Dabei ist es wichtig zu beachten, dass nicht beliebige Sprachelemente bearbeitet werden können. Oftmals existieren Abhängigkeiten unter ihnen, weshalb man sie in einem Gesamtkontext betrachten muss.

Aus dem Grund postuliert das Design-Team unterschiedliche Themenbereiche, in denen es die Sprachen weiterentwickelt – nicht zuletzt, um die Arbeit zu strukturieren. An der Stelle sei erwähnt, dass das Design-Team die Sprachen C# und VB.NET nicht getrennt betrachtet. Vielmehr sollen alle Überlegungen und Features für beide Sprachen Gültigkeit haben und in beide Einzug halten.