Erich Gamma und Dirk Bäumer im Interview

Visual Studio Code: Es geht um Wahlfreiheit und Performance!
Kommentare

Seit seinem Erscheinen im April 2016 erfreut sich Visual Studio Code großer Beliebtheit bei Entwicklern aus allen Lagern. Wir haben mit Erich Gamma und Dirk Bäumer, zwei der Köpfe hinter dem Projekt, über Microsofts Quelltext-Editor und dessen Entstehungsgeschichte gesprochen.

Herr Gamma, Herr Bäumer, Microsoft ist nicht mehr nur das Windows-Unternehmen, sondern hat sich für alle mögliche Plattformen geöffnet, sowohl in puncto Produkte, als auch für Entwickler. Welche Möglichkeiten sehen Sie durch diese neue Wahlfreiheit, jenseits von der Wahlfreiheit von Entwicklungsplattformen? In Ihrer Keynote auf dem Microsoft Technical Summit in Darmstadt haben Sie ja das Mantra “any developer, any app, any platform“ angesprochen. 

Erich Gamma: Microsoft nimmt das „Any“-Plattform-Prinzip sehr ernst: Auf Azure kann ich heute bspw. Linux deployen. Und wir sehen viele Entwickler heutzutage, die entwickeln auf dem Mac und deployen auf Linux. Auch sie können die Azure-Dienste für ihre Anwendungen nutzen.

Im Prinzip ist diese Plattformwahlfreiheit der entscheidende Punkt des Paradigmenwechsels?

Dirk Bäumer: Die Frage nach der Plattform ist eben nicht so einfach zu beantworten: Plattform meint meistens Entwicklungsplattform. Aber heute bedeutet es wo entwickle ich, wo builde ich, wohin deploye ich, wo laufe ich. Wie Erich sagt: Egal ob Sie auf dem Windows Server ganz normal mit .NET laufen oder in einem Docker-Container mit einer Node Application – man kann beides nach Azure deployen. Ob man unter Windows, Mac oder Linux entwickelt hat, ist vollkommen egal. Wo ich es gebaut habe, ob ich es mit TFS auf einer Windows-Maschine, auf einer Linux-Maschine in Azure oder auf einem lokalen Mac-Server gebaut habe, das ist uns eigentlich auch vollkommen egal. Die Plattformfreiheit ist in der ganzen Pipeline verankert und wirkt sich selbst auch bei den Tools aus: Wenn Entwickler Sublime mit TypeScript benutzen wollen, können sie das.

Es geht um „Choice“, wir geben den Entwicklern die Gelegenheit zu wählen.

Gamma: Es geht um „Choice“, wir geben den Entwicklern die Gelegenheit zu wählen. Und für mich ist das wie eine Slot Machine: Man hat die Plattform, IDEs, leichtgewichtige Tools, verschiedene Programmiersprachen. Je nach Kombination kann ich als Entwickler jetzt das Tool wählen, das mir am meisten zusagt. Und das kann heißen: ich entwickele auf Mac, ich mag IDEs, ich mag C# also nehme ich mir Visual Studio für Mac. Das ist Freedom auf Choice. Letztlich ist das die Entscheidung des Entwicklers.

Sie haben maßgeblich Eclipse mitentwickelt und Sie waren lange Distinguished Engineer bei IBM. Wie passen aus Ihrer Sicht die Offenheit von Microsoft und IBM zusammen?

Erich Gamma auf dem Technical Summit 2016 in Darmstadt.

Erich Gamma auf dem Technical Summit 2016 in Darmstadt (Bild: Microsoft).

Gamma: Ich kann zu IBM nicht viel sagen. Ich kann nur sagen, dass sich zum Beispiel im Rahmen der Zusammenarbeit mit dem Java Language Server, der ja auch von Visual Studio Code verwendet werden kann, eine schöne Zusammenarbeit mit den IBM Eclipse-Entwicklern ergeben hat. Wir haben im Rahmen eines Hackathons in unserem Labor mit den Eclipse Entwickler am Java Language Server, der auf den Eclipse Java Tools aufbaut, gearbeitet. Der Java Language Server verwendet unser offenes Language Server Protocol. Diese Offenheit hat das ermöglicht. Es ist ja auch ein Win-Win für sie [die Eclipse-Entwickler, die Red.], nicht? Wenn Orion dann auch den Language Server brauchen kann, dann kann das für sie auch ein Win-Win sein.

Ich möchte hier direkt anknüpfen: Sie haben beide umfangreiche IDE-Erfahrungen in Ihrer beruflichen Laufbahn gesammelt, um das mal untertrieben zu umschreiben. Was waren die wertvollsten Erfahrungen und Learnings aus der Eclipse-Zeit, die Sie dann in die Entwicklung von Visual Studio Code mit einbringen konnten?

Gamma: In der Eclipse-Zeit war sicherlich der Fokus auf die Erweiterbarkeit des Tools das Wichtigste. Ohne eine Vielzahl von Erweiterungen erreicht man die Entwickler einfach nicht. Ebenfalls soll es einfach sein, Erweiterungen zu entwickeln. Dazu braucht es gute Werkzeuge. In Eclipse kamen die Tools, um Erweiterungen zu schreiben, gleich mit. Diese Idee haben wir auch in Visual Studio Code übernommen. Das Ziel war, fünf Minuten nach der Installation schon die erste Erweiterung implementiert haben zu können.

Was wir noch aus der Eclipse-Zeit gelernt haben: Wenn man Extensions hat, dann muss man damit rechnen, dass es sehr viele davon gibt und damit muss man umgehen können. Bei Eclipse haben wir versucht, das mit „Lazy Loading“ zu erreichen. Wir haben außerdem bei Eclipse die Wichtigkeit von APIs erkannt, sprich wie wichtig stabile, konsistente und einfach erlernbare APIs sind. Da versuchen wir noch einen Schritt weiterzugehen bei Visual Studio Code.

Bäumer: Wir haben auch gemerkt, dass es schwierig war, neue Sprachen zu integrieren. Man hat in Eclipse einen Editor programmiert und nicht eine neue Programmiersprache hinzugefügt.

Gamma: Wir haben auch gelernt, dass man nicht alle Erweiterungen in der Implementierungssprache der Entwicklungsumgebung schreiben möchte, insbesondere, wenn man Erweiterungen für viele Sprachen unterstützen möchte. In Eclipse wurden alle Erweiterungen in Java geschrieben. Als die C++ Erweiterung für Eclipse entwickelt werden musste, haben wir in Java einen Parser für die C++ Sprache geschrieben. D.h. wir haben kein Dogfooding gehabt, keinen Feedback-Loop. Und vor allem: Wir haben alles nochmal neu gemacht. Deswegen: Eine IDE muss auch Polyglottie, also Mehrsprachigkeit für Erweiterungen, ermöglichen. In Visual Studio Code ermöglichen wir diese Mehrsprachigkeit, indem man mehrere Prozesse verwendet. Das ist sogar das erste, was wir gelernt haben: Mehrere Prozesse sind eine gute Sache. Nicht nur für Skalierbarkeit, sondern auch für den Re-Use. Denn die Wiederverwendbarkeit öffnet auch die Tür dafür, dass jemand eine Sprachinfrastruktur schreibt, die man mit mehreren Tools verwenden kann.

Mehrere Prozesse sind eine gute Sache. Nicht nur für Skalierbarkeit, sondern auch für den Re-Use.

Die zweite wichtige Erkenntnis, die wir hatten, war, dass man sich noch mehr vor Extensions schützen muss als in Eclipse. In Eclipse hat man sich mit „Lazy Activation“ geschützt: Erst wenn Extensions gebraucht werden, werden sie geladen. Man hat vielleicht noch Penalties eingeführt, Messungen gemacht und festgestellt: „Oh, das dauert jetzt aber lange!“. Wir wollten jetzt einen Schritt weitergehen. Wir haben festgelegt: Wir lassen Erweiterungen immer in einem separaten Prozess laufen, im sogenannten Extension Host Process. Das heißt, das gibt uns die volle Kontrolle. Wenn eine Extension Amok läuft, ist unser UI, das Tool, immer noch responsive, und der Benutzer kann immer noch seine Änderungen speichern, auch wenn eine Extension eine unendliche Schleife programmiert hat.

Bäumer: Natürlich sind auch noch die Native Calls zu erwähnen. D.h. der Visual Studio Code Hauptprozess überlebt auch Abstürze von Extensions.

Gamma: Genau. Und das Dritte ist: Das API ist wichtig und muss natürlich stabil bleiben, aber wir wollten es noch auf eine höhere Stufe bringen als in Eclipse. Eclipse hat ein API, das sich aus den APIs der Plug-ins zusammensetzt. Jedes Plugin publiziert ein API. Das gesamte API ist die Summe der APIs aller Plugin-APIs. Es ist sehr schwierig, das API so homogen und konsistent zu halten. In Visual Studio Code haben wir gesagt: Wir machen ein High-Level-API. Wir haben die volle Kontrolle über das API. Das erreicht man auch dadurch, dass die Extension in einem separaten Prozess läuft, die über ein Protokoll mit dem Hauptprozess kommuniziert. Da kann eine Extension machen, was sie will. Sie kommt nur an das heran, was über das Protokoll freigegeben ist. Das gibt uns mehr Kontrolle. Das sind so einige zentrale Punkte, die Visual Studio Code besonders machen.

Ein weiterer Punkt der uns wichtig war, war das Ökosystem für Extensions. Wir wollten von Anfang an einen Marketplace für Extensions haben. Das haben wir in Eclipse übersehen. Wir dachten, „Ja, Plugins sind wichtig.“ Aber wir hatten übersehen, dass mit einem Markt ein ganzes Ökosystem entstehen kann, wo man Extensions einfach finden kann, weil diese Funktion schon ins Tool integriert ist. Die Installation von Extensions funktionierte in Eclipse gut, aber wir haben eben nicht einen Marketplace für Plugins gehabt. Das haben wir diesmal in Visual Studio Code von Anfang an anders gemacht.

Visual Studio Code ist mit Webtechnologien entwickelt, schimmern diese Technologien auch im API durch?

Gamma: Extensions laufen in einem separaten Prozess und haben keinen direkten Zugriff auf die HTML-Struktur oder den DOM von Visual Studio Code. Wir erlauben aber zum Beispiel, dass man in einem Bereich HTML darstellen kann, dies passiert aber isoliert. D.h. man kommt von diesem Bereich nicht an die HTML-Struktur von Visual Studio Code heran. Wir verstecken das HTML, die Struktur unseres DOMs, unseres Hauptprozesses komplett vor den Erweiterungen. Dies erlaubt uns die HTML-Struktur zu ändern, ohne dass Erweiterungen gebrochen werden. Eine Erweiterung kann, wenn sie will, HTML benutzen und ein neues UI-Element hinzufügen. Aber auch dieses Element läuft in einem eigenen Prozess. Wir verwenden dazu die sogenannten Webviews. Eine WebView ist ein sicheres iFrame, bei dem der Inhalt in einem anderen Prozess abläuft. Also auch hier verwenden wir Prozesse, um solche Erweiterungen zu isolieren.

Und damit sich Visual Studio Code wie eine Desktop-App verhält und anfühlt – was waren dabei die größten Herausforderungen?

Gamma: Performance ist eine Herausforderung, schließlich wird Visual Studio Code mit anderen Native Apps verglichen. Des Weiteren Startup-Time, Load-Time, Rendering-Time, Responsiveness. Da steckt sehr viel Engineering-Schweiß dahinter, um das zu erreichen. Performance ist ein Thema, an dem wir dauernd arbeiten und wir wollen sie laufend verbessern. Wir haben verschiedene Bereiche des Editors mehrmals im Hinblick auf eine bessere Performance umgeschrieben. Dabei helfen uns die Performance-Werkzeuge, die einem im Browser zu Verfügung stehen enorm.

Performance ist eine Herausforderung, schließlich wird Visual Studio Code mit anderen Native Apps verglichen.

Bäumer: Mit HTML kann man sehr schnell sehr schöne UIs bauen. Aber es braucht sehr viel Engineering-Aufwand, um ein gutes, wartbares User Interface mit HTML und JavaScript zu entwickeln.

Gamma: November war für uns ein Performance-Monat. Unter anderem haben wir den Quellcode instrumentiert, so dass wir Performance-Daten auf den verschiedenen Plattformen sammeln können. Dabei haben wir eine große Varianz bezüglich der Startzeit gefunden, die wir jetzt weiter analysieren.

Visual Studio Code ist hauptsächlich in HTML5 und auch in TypeScript implementiert. Sie haben für die Desktop-Integration Electron von GitHub verwendet. Was gab den Ausschlag für diese Wahl?

Gamma: Wir haben schon länger an Entwicklertools gearbeitet, die in einem Browser ablaufen können. Deshalb hatten wir eine Code-Basis, die bereits in HTML5 implementiert war und Node nutzte. Als die Anforderung kam „was im Browser läuft, soll jetzt auf dem Desktop laufen“ passte Electron (damals hieß Electron noch Atom Shell) von Github sehr gut. Wir haben zuerst mit Node Webkit experimentiert. Es wurde aber schnell klar, dass es bei Electron eine engagierte und sehr aktive Community gibt.

Die Sie nicht bereut haben?

Gamma: Nein, wir haben es nicht bereut. Electron entwickelt sich schnell weiter und das passt gut zu unserem ebenfalls schnellen Entwicklungszyklus. Es gibt gewisse Lücken, aber wir probieren, diese zu füllen, bspw. im Bereich Accessibility. Dazu haben wir auch an Hackathons von Github mitgemacht. Und wir machen auch Pull Requests. Es ist also nicht so, dass wir nur Electron konsumieren.

In den Anfängen in der Entwicklung von Visual Studio Code gab es viele Limitierungen. Wenn ich es mich richtig erinnere, haben Sie zu Beginn sogar ohne Mausunterstützung gearbeitet – getreu dem Motto „Eat your own Dogfood“.

Bäumer: Das mit der Maus lag damals vor allem daran, dass der Editor noch keine Mausunterstützung implementiert hatte. Wir haben also wirklich früh mit Dogfooding angefangen.

Können Sie nochmal schildern, warum Sie dieses Prinzip, „Eat Your Own Dogfood“ so aggressiv verfolgt haben. Warum war das so wichtig für Sie?

Gamma: Das ist das Schöne an Entwickler-Tools, man kann sie selbst benutzen, man spürt die Probleme selbst, man spürt den Schmerz selbst, man spürt die Schönheit selbst. Deswegen war uns das auch so wichtig. Denn man kriegt kein gutes Entwickler-Tool hin, wenn man es nicht selbst braucht. Auch die Tatsache, dass wir selbst täglich auf die neueste Version wechseln – und unsere Community dank des Insider Channels dies auch tun kann – macht eine ganz neue Form des Feedbacks möglich. Man muss nicht mehr einen Monat warten bis Feedback kommt. Wir kriegen täglich Feedback von den Leuten, die mit der Visual Studio Code Version im Insider Channel arbeiten. Und genau das ist eine Art „stress reduction“. Zusätzlich kann man so neue Ideen laufend testen. Eine Idee kann gut im Kopf sein, aber wenn man sie selbst benutzt, sieht man wo noch mehr poliert werden muss. Für mich ist das kontinuierliche Verarbeiten von Feedback eine Qualitäts- und eine Innovationsfrage.

Wenn man zurückblickt: Sie haben beide ja eine große Erfahrung in der Entwicklung solcher Tools, aber vor 15, 20 Jahren war die Veröffentlichung von täglichen Builds nicht möglich. Können Sie sich das überhaupt noch vorstellen, eine Entwicklerwelt ohne diese Möglichkeit?

Gamma: Nun, es hat vor 15 Jahren schon die Nightly Builds in Open Source Projekten gegeben. Aber da hat man eigentlich nur geschaut: Gibt es Compile-Fehler? Heute erlauben wir, dass ein Benutzer einfach den Nightly Build installieren kann und ihn gleichzeitig mit dem stabilen Build verwenden kann. Übrigens nennen wir den Nightly Build jetzt „Insider Build“. Hat der Insider Build ein Problem, kann der Benutzer einfach auf den stabilen Build wechseln.

Dirk Bäumer auf dem Technical Summit 2016 in Darmstadt (Bild: Microsoft).

Dirk Bäumer auf dem Technical Summit 2016 in Darmstadt (Bild: Microsoft).

Bäumer: Man muss auch sagen, dass wir dazu sehr viel in Infrastruktur investiert haben, um das möglich zu machen. Aber seitdem wir über diese Infrastruktur verfügen, ist der Overhead für das Entwicklerteam, sprich das Betreiben klein. Es ist also eher positiv, auch weil Leute immer wieder nach Features fragen und wir antworten können „Benutzt den Insider Build ab Tag X und gebt uns Feedback!“. Und meist reagieren die Leute mit „Oh ja, wenn das schon drin ist, testen wir das doch gleich mal!“

Gamma: Das ist die Idee von Side-by-side-installs und Channels. Der Benutzer kann gleichzeitig mehrere Versionen installiert haben und diese Versionen werden über Channels mit unterschiedlicher Häufigkeit aufdatiert. Der Insider Channel wird täglich aufdatiert und der Stable Channel monatlich. Geht etwas im Insider Channel nicht, wechsle ich auf die Version vom Stable Channel und habe halt das neueste Feature nicht.

Stichwort Entwicklerteam. Wie sah die Arbeit für Sie in den letzten Jahren im Team aus? Sie waren in Zürich. Wie muss man sich das vorstellen, wie groß ist das Team, wie lief der Arbeitsalltag ab?

Gamma: Im August vor fünf Jahren kam ich als erster Mitarbeit zu Microsoft und jeden Monat kam ein weiteres Teammitglied dazu, bis zum darauffolgenden Februar. Du [Dirk Bäumer, die Red.] warst einer der letzten, die Älteren kamen am Schluss [grinst Dirk Bäumer an, die Red.]. Am Anfang kamen eher die Jüngeren.

Nach drei Monaten hatten wir den ersten Release, und seitdem liefern wir alle Monate einen neuen Release aus.

Wir hatten einen Raum im Microsoft-Gebäude und dort haben wir losgelegt. Wir saßen rund um einen Tisch und begannen mit der Entwicklung vom ‚Monaco Editor‘. Ein Code-Editor, der im Browser läuft. Den ersten Backlog haben wir auf einer Serviette während einem Mittagessen erstellt. Nach drei Monaten hatten wir den ersten Release, und seitdem liefern wir alle Monate einen neuen Release aus. In der Zwischenzeit haben wir ein tolles Büro erhalten, am Tagesablauf hat sich aber nicht viel geändert. Ein Standup-Meeting, dass immer länger dauert, als es in den agilen Lehrbüchern steht, das heißt so ungefähr eine Stunde und dann ein gemeinsamer Teamlunch. Wir hatten von Anfang an eine sehr gute Redmond-Liaison. Es war ein Visual-Studio-Programm-Manager. Er kannte sich sehr gut mit Eclipse aus und war früher für die kompetitive Analyse von Visual Studio und Eclipse zuständig. Er war immer unsere Verbindung zu Redmond, er hat uns dort repräsentiert und dazu tolle Demos von unserem Fortschritt gemacht. Das war sehr wichtig, um stets die Nähe zur Zentrale zu haben. Wir verstanden uns gleich von Anfang an bestens mit dem Programm-Manager. Er fand in Eclipse sei alles besser als in Visual Studio. Wir meinten natürlich bei Visual Studio sei alles besser als in Eclipse. Das Gras ist eben immer grüner auf der anderen Seite des Zauns.
Innerhalb von drei Jahren sind wir dann auf acht Teammitglieder gewachsen. Nachdem wir dann Visual Studio Code Version 1.0 ausgeliefert hatten, haben wir den nächsten Schritt gemacht und begonnen, auch in Redmond ein Team aufzubauen. Das war im April/Mai 2016.

Abschließend: Wie wird es weitergehen mit Visual Studio Code? Was sind die nächsten Ziele, auf was dürfen sich die Nutzer freuen?

Gamma: Wir wollen ein transparentes „Open Source“-Projekt sein. Unsere Roadmap ist auf der Website, wir haben einen sechsmonatigen Planungszyklus und sind jetzt gerade am Ende eines solchen. Mit der Connect(); und der Build  Konferenz haben wir zwei wichtige Events im Jahr, die in sechsmonatigem Abstand stattfinden und das entspricht auch unserem Planungszyklus. Die Connect();-Phase ist fertig, und wenn man die Roadmap anschaut, sieht man entsprechend viele Checkmarks. Wir sind jetzt dabei die Roadmap für die nächsten sechs Monate zu machen. Einerseits wollen Entwickler auch andere Versionskontrollsysteme verwenden können als Git. Hier planen wir ein Source-Control-Provider-API, das es Entwicklern erlaubt, ein anderes Versionskontrollsystem zu nutzen, zum Beispiel das Microsoft TFS Version Control System oder Subversion. Dann gibt es Bedürfnisse im Bereich UI, gewisse Erweiterungen anzubieten, bspw. einen Explorer. Sprich: Im Fall einer Datenbank habe ich nicht das Filesystem, das ich exploriere, sondern ein Datenbankschema. Hier überlegen wir, was wir auf API-Seite machen können.

Und was uns ebenfalls interessiert ist, den Inner Loop noch besser abzudecken. Also auf Edit, Build, Debug, Commit. Was noch fehlt ist Testing. In diesem Bereich wollen wir schauen, was wir fürs Testing auf der Seite von APIs und im Tool anbieten können. Es gibt zwar schon Testing-Extensions. Aber wir überlegen, wie man einen gemeinsamen Nenner – im Bezug auf die Plattform – finden kann, um zu vereinheitlichen, wie Tests ausgeführt werden.

Das sind einige Punkte, die auf der Agenda stehen. Ganz wichtig dabei wird wieder das Feedback, das wir natürlich berücksichtigen werden. Ein populärer Feature Request ist zum Beispiel eine sogenannte Minimap des Codes, die im Editor angezeigt wird. Das werden wir natürlich explorieren.

Vielen Dank für das Gespräch!

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -