«Wir wollen alle Entwickler»

Anlässlich eines Besuchs in der Schweiz hatte «Swiss IT Magazine» exklusiv Gelegenheit, Jason Zander Corporate Vice President Visual Studio bei Microsoft, zum aktuellen Stand der Microsoft-Entwicklungs-Tools und zur Zukunft der Windows-Entwicklung zu befragen.

Swiss IT Magazine: Herr Zander, Mitte September ging die neue Microsoft-Entwicklerkonferenz Build über die Bühne. Was sind aus Ihrer Sicht die wichtigsten Ankündigungen?
Jason Zander: Das wichtigste Announcement war natürlich Windows 8, sowohl die Client- als auch die Server-Version mit mehr als 200 neuen Features. Für Entwickler gab es zwei wichtige Ankündigungen: Erstens der Release von «Visual Studio 11» – das ist ein Codename – als Preview, zweitens die Ankündigung des Team Foundation Service auf Windows Azure, also Team Foundation Server in der Cloud.

Was bietet «Visual Studio 11» an Neuerungen?
Es ist ein bedeutender Release, hier die wichtigsten Punkte: Zunächst gibt es Änderungen auf der Engine-Seite, nämlich die neue SP1-Version von .NET 4.5, dazu kommt mit den neuen Keywords async und await neuer Support für asynchrone Programmiermodelle in den Compilern für C# und Visual Basic. In die IDE haben wir eine ganze Menge von Produktivitätsverbesserungen eingebaut, darunter die populären, bisher separat erhältlichen Productivity Power Tools. Auf der höchsten Ebene sprechen wir vom Application Lifecycle Management (ALM), hier gibt es neben Architect, Developer und Test die zwei neuen Rollen Product Owner für das Requirements Engineering und Operations.

Haben Sie persönliche Lieblingsfeatures?
Eines ist Pixel Debugging für DX, das ist sehr cool für die Grafik-orientierte Entwicklung. Man kann im Debug-Modus einen Pixel auf dem Screen anklicken, zu Visual Studio wechseln und erhält ein Frame-Trace-Protokoll, das genau nachvollzieht, wie es vom leeren Frame Buffer zu diesem Pixel in der womöglich falschen Farbe kam und welcher Source Code dafür veranwortlich ist. Genial finde ich auch Code Clones, eine Suchfunktion für sich ähnelnde Code-Stellen, die nicht einfach einen Stringvergleich macht, sondern den Syntaxbaum berücksichtigt und so strukturell identische Stellen auch bei unterschiedlichen Variablen- und Konstantennamen findet.


Zurück zum Application Lifecycle Management: Wie sieht Microsofts ALM-Philosophie aus?
Als wir den Team Foundation Server entwickelten, haben wir viele Entwickler zu ihren Bedürfnissen und Problemen befragt. Die erste Antwort hiess immer «Collaboration». Wann immer ein Software-Projekt scheiterte, war das Problem die Zusammenarbeit der Beteiligten vom Architekten bis zum Tester und darüber hinaus. Application Lifecycle Management bedeutet für uns also in erster Linie, die Projektteilnehmer so zusammenzubringen, dass sie effizient und bequem zusammenarbeiten können. ALM beginnt mit der Definition, was für ein Produkt man überhaupt erzeugen will, geht weiter zur Architektur, zum Codieren, Testen und zur produktiven Installation bis hin zum Aktualisieren und zur Fehlerbehebung. Das ist der Lebenszyklus einer Applikation. ALM stellt für jede der beteiligten Rollen ein spezifisches Toolset zur Verfügung.

Und was spricht für den Team Foundation Server als ALM-Lösung?
Mit TFS bieten wir den grossen Vorteil, dass der Support für alle Rollen auf einem zentralen Server basiert und alle Beteiligten mit den gleichen Assets arbeiten können. So lösen wir das Collaboration-Problem. Unter dem Motto «Team Explorer Everywhere» unterstützen wir zudem ALM nicht nur für Visual Studio und
.NET, sondern auch für die Java-Welt mit Ver­sionen für Mac OS X und Unix sowie einem Eclipse-Plug-in. Es gibt ja oft Projekte, bei denen ein Teil der Entwicklung auf Windows-Plattformen und ein anderer zum Beispiel mit Java erfolgt.

Wie und wann unterstützt der Team Foundation Server die Zusammenarbeit konkret?
Wir unterstützen mit der neuen Version des Scrum Template, das Methoden wie Task Boards und Backlogs integriert, die agile Entwicklung noch besser als bisher. Im Moment sind die neuen Funktionen als Preview verfügbar, dann wird wie bei jedem Produkt eine Betaphase folgen und dann schliesslich die definitive Version. Ein konkretes Release-Datum für die neue TFS-Ausgabe können wir aber noch nicht angeben.


Und wie geht bei Microsoft selbst die Entwicklung von Visual Studio vor sich?
Als Entwicklungsteam haben wir auch unsere eigenen Ideen und Wünsche berücksichtigt. Wir nutzen für die Weiterentwicklung von Visual Studio und .NET natürlich Visual Studio, und insbesondere auch den Team Foundation Server – unsere TFS-Installation umfasst derzeit 17 Terabyte an Assets. Wir arbeiten mit Scrum als Entwicklungsmethodik und nutzen die neuen Scrum-Features. Der neue Agile-Support gehört zu meinen Lieblingsneuerungen. Er funktioniert sehr gut, bringt die Teams zusammen und ist sehr effizient. Aus meiner Perspektive als Engineering-Manager erlaubt mir TFS zu sehen, was 1500 Leute tun. Das wäre sonst eine ziemlich schwierige Aufgabe.

Wie sieht die Zukunft von .NET aus – im Diagramm zu den Windows-8-Entwicklungsplattformen erscheint .NET ja nur ganz am Rande.
Eine Anmerkung vorab: Unter www.buildwindows.com gibt es eine Menge Material zur Entwicklung für Windows 8 – Videos von den Build-Keynotes, Foren, Beispiel-Apps und andere Downloads. Wer interessiert ist, erfährt hier alle wichtigen Details. Das erwähnte Diagramm zeigt auf der linken Seite alles, was es für die Entwicklung Touch-orientierter Metro-Style Apps braucht. Rechts erscheint die Plattform für herkömmliche Desktop-Anwendungen. Der Unterschied liegt vor allem bei der Präsentation und der Client-Logik: Metro setzt neben XAML und C# auch auf HTML und Javascript – darunter liegt aber das gleiche Common Language Runtime, nur halt mit zusätzlichen APIs für Javascript. Eine gewisse Verwirrung mag dadurch entstehen, dass für Desktop-Apps die .NET-Runtime-Libraries zum Einsatz kommen, bei Metro-Apps dagegen WinRT. Deshalb steht «.NET» nur auf der Desktop-Seite, obwohl auch für die Touch-Apps viele .NET-Technologien wie C# und CLR gelten. Das Problem ist auch, dass «.NET» ein sehr breiter Begriff ist – für viele heisst .NET vor allem Managed Code, und Managed Code gibt es auf beiden Seiten.

Das .NET-Know-how eines Entwicklers wird also nicht überflüssig?
Auf keinen Fall. In einer meiner Build-Sessions habe ich zum Beispiel eine mit Visual Studio 2005 entwickelte Windows-Forms-Anwendung nach Visual Studio 11 portiert und neu kompiliert – sie läuft nun unter Windows 8 ohne jedes Problem. Der Aufwand für die Portierung war gering, obwohl die App ja ursprünglich fürs .NET Framework 2.0 und CLR 2 entwickelt war und nun unter .NET 4.5 und CLR 4 läuft. Natürlich ist der Aufwand deutlich höher, wenn man eine Desktop-App in eine waschechte Metro-App mit Touch-Funktionalität umwandeln will.

Wieso kommen für die Metro-Apps neben XAML und C# auch HTML und Javascript hinzu – wollen Sie damit neue Entwickler anziehen?
Wir wollen natürlich alle Entwickler auf der Windows-Plattform. Die .NET-Entwicklergemeinde ist sehr stark und wächst nach wie vor. Wir sehen aber auch, dass es sehr viele wirklich gute HTML/Javascript-Programmierer gibt, und die möchten wir auch für die Microsoft-Plattformen gewinnen.

Microsoft geht also nicht völlig zu Web-Standards über, so dass herkömmliche Programmierer nichts mehr zu lachen haben?
Auf keinen Fall – sonst sähe das Diagramm ja ganz anders aus.


Was muss ein Entwickler dazulernen, wenn er auch WinRT-basierte Metro-Apps erstellen will?
Er kann seine bestehenden Programmiersprachen und Kenntnisse weiter verwenden. Wenn er bisher mit Javascript gearbeitet hat, kann er weiter damit arbeiten, das gleiche gilt für C#. Was neu ist, sind die Namespaces und natürlich das Design der Applikation – es sollen ja schliesslich erstklassige Touch-Apps entstehen. WinRT ist ausschliesslich als Basis für Metro-Apps in Windows 8 konzipiert, es gibt also keinen Grund, Windows Runtime auch auf ältere Windows-Versionen zu portieren und für Desktop-Anwendungen zu nutzen.
WinRT basiert auf COM, ist das nicht eine ziemlich alte Technologie?
Das stimmt, WinRT ist mit C++ gebaut. Wir lieben C++. Grosse Teile von Windows sind in C++ geschrieben, und wir haben neue C++-orientierte Features in Visual Studio 11 integriert, sowohl beim Compiler als auch in der IDE. C++ gibt es schon lange, aber es ist nach wie vor eine grossartige Programmier­sprache.

XAML gibt es ja in Silverlight, in der WPF und auch für die View-Ebene der Metro-Apps. Sind diese Varianten kompatibel?
XAML in Silverlight und WPF sind ziemlich eng verwandt. Nicht exakt gleich, aber die Unterschiede sind gering. Ähnlich verhält es sich mit dem XAML-Stack für Metro. Die Unterschiede liegen vor allem im Zweck der mit XAML beschriebenen Elemente: Ein Hover-Effekt macht für eine Maus-orientierte Desktop-Anwendung Sinn, aber was soll ein Hover-Effekt bei einer Touch-App? Solche Unterschiede in der Bedienphilosophie sind ein Grund für die Unterschiede zwischen den XAML-Varianten. Ein weiterer Grund ist, dass XAML für Metro natürlich zu WinRT passen muss. Zum Beispiel ist Support für das Vor- und Rückwärts-Scrollen bei Touch-Apps direkt in WinRT eingebaut, und dazu müssen entsprechende XAML-Statements passen, die für Desktop-Apps nicht gelten. Als Entwickler begrüsse ich das durchaus – es bringt wenig, eine App 1:1 von einem Smartphone auf einen PC zu bringen, wo die Oberfläche dann einfach riesig auf dem Bildschirm erscheint.

Gibt es eine Zukunft für Silverlight?
Wir haben eben den Releasekandidaten von Silverlight 5 freigegeben. Was die weitere Zukunft betrifft: Wir äussern uns prinizpiell nicht zu Plänen für kommende Produktver­sionen. Im Moment konzentrieren wir uns auf die aktuelle Version 5 und sehen zu, dass sie erfolgreich angenommen wird.


Bleibt Silverlight die Plattform für die Entwicklung von Windows-Phone-Apps?
Vor kurzem haben wir Windows Phone 7.5 «Mango» mit vielen coolen neuen Features freigegeben. Mango nutzt den XAML-Stack, man kann Silverlight-Anwendungen mit C# oder Visual Basic programmieren. Ich erwarte, dass das auch so bleibt. Auch hier gilt: Wir haben bisher nichts zu künftigen Versionen von Windows Phone angekündigt. Eine heute funktionierende Windows-Phone-App dürfte aber auch auf künftigen Systemver­sionen laufen. (ubi)