zurück zum Artikel

Erich Gamma ist als Mitbegründer der Gang of Four Teil der bekanntesten Bande im Reich der Informatik. Mittlerweile ist er bei Microsoft untergekommen, und statt Java steht nun JavaScript auf seiner Tagesordnung. Ein Wechsel, der ab und an für leichte Wehmut sorgt.

Erich Gamma ist als Mitbegründer der Gang of Four Teil der bekanntesten Bande im Reich der Informatik. Mittlerweile ist er bei Microsoft untergekommen, und statt Java steht nun JavaScript auf seiner Tagesordnung. Ein Wechsel, der ab und an für leichte Wehmut sorgt.

heise Developer: Vor vier Jahren bist du von IBM zu Microsoft gewechselt und seither war es eher ruhig um dich. Was hast du in der Zeit getrieben?

Erich Gamma: Ich habe eine neue Herausforderung gesucht und wollte etwas Anderes machen, deshalb der Wechsel. Die Herausforderung war, eine Antwort auf die Frage zu finden, was man mit Online-Coding alles anstellen kann. Also wie weit kann man mit Programmierung im Browser gehen, was ist möglich und wie kann man Werkzeuge weiterbringen, wenn man den Browser einbezieht.

Ergebnis der Arbeit sind unterschiedliche Komponenten, die in verschiedenen Produkten untergekommen sind. Zum Beispiel ist ein Code-Editor entstanden, der im Browser läuft und in diversen Microsoft-Projekten wie OneDrive und im Azure Portal zum Einsatz kommt. Mit Visual Studio Online "Monaco" können Azure Websites im Browser bearbeitet werden. Das neueste Projekt – Visual Studio Code – setzt auf dieselbe Technik, läuft aber auf dem Desktop als eigenständige Anwendung.

Zurückblickend waren mein Team und ich vier Jahre lang eine Art Start-up-Unternehmen innerhalb von Microsoft, das versucht hat, mithilfe des Browsers die Arbeit von Entwicklern zu erleichtern.

heise Developer: Visual Studio Code wurde Ende April auf Microsofts Build-Konferenz vorgestellt. Kannst du dazu noch ein bisschen mehr erzählen, wo du doch an der Entwicklung beteiligt warst?

Erich Gamma: Die Idee hinter dem Editor war es, ein Werkzeug für mehrere Plattformen anbieten zu können. Microsoft möchte die Cross-Plattform-Entwicklung vorantreiben, wie auch die Ankündigung von .NET als Cross-Plattform-Angebot aus dem letzten November zeigt. Wenn man so etwas ankündigt, braucht man auch Tools, die über die verschiedenen Plattformen hinweg funktionieren.

Mit Visual Studio Code wollten wir ein einfaches Tool für Webentwickler bauen, das aber wichtige Funktionen wie IntelliSense und entsprechende Debugging-Möglichkeiten enthält. Das Tool sollte sich eher wie ein Editor verhalten und keine vollständige Entwicklungsumgebung werden.

Visual Studio Code ist hauptsächlich in TypeScript und mit HTML5 implementiert. Für die Integration in den Desktop verwenden wir Electron [2], ein von GitHub entwickeltes Projekt.

Interessant ist auch, dass Visual Studio Code eine Tools-Service-Architektur verwendet, die es erlaubt, Dienste wie die Unterstützung von C# in verschiedenen Tools einzusetzen. Dazu arbeitet mein Team auch in Open-Source-Projekten an solchen Services mit. Ein Beispiel dafür ist das OmniSharp [3]-Projekt.

Pro und contra IDEs

heise Developer: Wenn man sich deine Vergangenheit ansieht, hast du durch die Mitarbeit an Projekten wie Eclipse allerdings viel Erfahrung mit IDEs. Warum das nicht nutzen?

Erich Gamma: Ich liebe Eclipse natürlich immer noch, aber IDEs haben den Anspruch, viele Funktionen zu integrieren. Dadurch werden sie mit der Zeit immer schwergewichtiger und damit auch langsamer. Auf der anderen Seite gibt es Editoren, die auf Geschwindigkeit und für die effiziente Benutzung mit der Tastatur ausgelegt sind. Editoren und IDEs haben ihren Platz. Ein Editor hat auch nicht den Anspruch, alle Techniken zu integrieren. Es ist ok, sie über die Kommandozeile zu nutzen. Mit Visual Studio Code versuchen wir die Leichtgewichtigkeit eines Editors zu bewahren, aber auch Kernfunktionen, die man aus IDEs kennt und liebt, wie IntelliSense, Navigieren im Code, Refactorings und Debugging zu integrieren.

heise Developer: Gibt es da Unterschiede zu den Java-Entwicklern aus deinen Eclipse-Tagen?

Erich Gamma: Java-Entwickler leben quasi immer in ihrer IDE und der Workflow ist von der IDE vorgegeben und es geht ihnen gut so. Viele Webentwickler bevorzugen aber einen Editor, weil er schneller ist und per Kommandozeile mit anderen Tools dieser Szene, Grunt oder Gulp etwa, gemeinsam genutzt werden kann. Solche eher offenen Workflows wollen wir mit Visual Studio Code unterstützen. Auf diese Art kann eine neue Technologie sofort benutzt werden und man muss nicht warten, bis sie in die IDE integriert ist.

heise Developer: Habt ihr euren Editor ab einem gewissen Punkt auch für dessen Weiterentwicklung benutzt?

Erich Gamma: Wir haben etwa vor vier Jahren mit dem Projekt angefangen, aber bereits nach vier Monaten habe wir nur noch mit unserem Tool gearbeitet. Obwohl es am Anfang viele Limitierungen hatte. Zum Beispiel hatten wir am Anfang keine Unterstützung fuer die Maus. Wir betreiben "eat your own dog food" ganz bewusst aggressiv. Dies hilft uns nicht nur bei der Qualität, sondern es entstehen dabei auch immer wieder gute Ideen, die man dann ausprobieren möchte.

heise Developer: Gibt es im Entwicklungsprozess trotzdem Momente, in denen du auf Visual Studio zurückgreifst?

Erich Gamma: Durchaus, durch die Tools-Service-Architektur ist es möglich, Services in anderen Sprachen als TypeScript oder JavaScript zu schreiben. So ist zum Beispiel die Unterstützung von C# in C# implementiert. Visual Studio hat einen guten C#-Debugger, der auch das sogenannte Async Debugging beherrscht. Das kann Visual Studio Code noch nicht, deshalb kommt an der Stelle Visual Studio zum Einsatz. Ich schätze aber, dass mein Team mehr als 90 Prozent der Zeit in Visual Studio Code verbringt.

Organisation, JavaScript und Open Source

Prozesse weniger hoch aufhängen

heise Developer: Wie bereits anklang, bist du einer der Erfinder von Eclipse. Als du noch für die IDE unterwegs warst, hast du gern über den Eclipse Way geredet, also auch, wie man über das Jahr hinweg an dem Projekt arbeitete. Finden sich immer noch Herangehensweisen aus dieser Zeit in deinen Arbeiten?

Erich Gamma: Wir machen immer noch gewisse Dinge ähnlich. Es gibt beispielsweise auch jetzt noch vier Wochen dauernde Sprints oder Iterationen. Am Ende der Iteration produzieren wir ein "New & Noteworthy"-Dokument mit den neuen Funktionen. Dafür praktizieren wir jetzt Daily Standups, was wir bei der Arbeit an Eclipse nur wöchentlich gemacht haben. Es war uns von Anfang an wichtig, möglichst leichtgewichtige Vorgehen zu verwenden. Das fing alles nur mit Klebezetteln an einem Whiteboard an.

Unser Team ist langsam und kontinuierlich gewachsen. Heute braucht es daher etwas mehr Tools, weil wir über die Standorte Redmond und Zürich verteilt sind. Dazu verwenden wir einen Teil der Planungs-Tools von Visual Studio Online.

heise Developer: Gibt es denn viel Interaktion mit anderen Entwicklerteams bei Microsoft?

Erich Gamma: Als Start-up-Unternehmen innerhalb von Microsoft sind solche Interaktionen natürlich lebensnotwendig, sonst wird unsere Technologie ja nicht in anderen Produkten eingesetzt. In Microsoft verwendet man für diese gemeinsame Zusammenarbeit den Begriff Partnering. Beziehungen müssen aktiv gepflegt werden und eine wichtige Rolle dabei spielt der sogenannte Program Manager. Seine Aufgabe ist es, eine Brücke zwischen Nutzern und Entwicklerteam zu schlagen. Unser Program Manager sitzt deshalb zum Beispiel in Redmond und nicht bei uns in Zürich.

Lingua franca der Cross-Plattform-Entwicklung

heise Developer: Du hattest schon mit C++ und C zu tun, in deinem Buch zu Design Patterns kommen auch Beispiele aus Smalltalk vor, du hast viele Jahre mit Java zu tun gehabt und nun bist du bei JavaScript angekommen. Wie kam es zu der letzten Umstellung?

Erich Gamma: Der Verbreitung von JavaScript kann man schlicht nicht ausweichen. JavaScript kommt heute nicht mehr nur im Browser, sondern auch auf dem Server und für das Erstellen von Cross-Plattform-Tools zum Einsatz. JavaScript übernimmt so die Rolle von Java, wenn es um Cross-Plattform-Entwicklung geht.

Am meisten vermisst habe ich bei der Umstellung die Tools. Mit der Unterstützung von Refactoring, Quick Fixes und so weiter kann Code sehr einfach umgebaut oder verbessert werden. Eine Methode in JavaScript umzubenennen ist nicht trivial und es braucht eine gute Testabdeckung oder schlicht Mut dazu. Da der JavaScript-Code nicht einfach geändert und umstrukturiert werden kann, besteht die Gefahr, dass der zu faulen beginnt.

Hier hilft natürlich TypeScript. Die Einführung von optionalen Typen ermöglicht die Entwicklung von intelligenten Tools. Mein Team war übrigens der erste Partner vom TypeScript-Team. Sobald wir in unserem Projekt mehr als 100.000 Zeilen geschrieben hatten, haben wir uns entschlossen, den Code von JavaScript auf TypeScript umzuschreiben. Eine Entscheidung, die wir bisher nicht bereut haben – das finden sogar die hart gesottenen JavaScript-Entwickler in meinem Team.

heise Developer: Würdest du also TypeScript JavaScript in großen Projekten den Vorzug geben?

Erich Gamma: Ja, das wäre meine Empfehlung. Am Anfang, als TypeScript verfügbar wurde, gab es praktisch nur in Visual Studio eine gute Tool-Unterstützung dafür. Das hat sich mittlerweile geändert. Es gibt TypeScript-Erweiterungen für die meisten Editoren und IDEs. Aber auch Visual Studio Code eignet sich, da es aus etwa 300.000 Zeilen TypeScript-Code besteht. Sie wurden ausschließlich mit dem Editor selbst entwickelt, weshalb die Unterstützung der Sprache gut ausgereift ist.

heise Developer: Nachdem du jetzt einige Jahre mit JavaScript verbracht hast und dich vorher so ausführlich mit Design Patterns beschäftigt hast, gibt es Dinge, die dir in der Sprache besonders auffallen, was Muster angeht?

Erich Gamma: JavaScript war ursprünglich nicht für grössere Applikationen entwickelt worden. Es fehlten Konstrukte für Module, Klassen oder die asynchrone Programmierung mit Callbacks. Muster haben diesen Mangel teilweise kompensiert. Mit ECMAScript 6 beziehungsweise ECMAScript 2015 sind diese Unzulänglichkeiten endlich behoben und die Konstrukte stehen zur Verfügung.

Interessant ist auch die Mustersuche in JavaScript-Bibliotheken und -Frameworks. Interessanterweise findet man dort Muster, die man auch von Java her kennt. Zum Beispiel trifft man in Angular auf Dependency Injection und Data Binding. Knockout setzt auf das Model-View-ViewModel-Muster und so weiter. Das zeigt, dass viele Muster sprachunabhängig sind. Wenn ich nicht bereits ein Buch zum Thema geschrieben hätte und wüsste, wie viel Arbeit damit verbunden ist, fände ich es wirklich spannend, über all die Muster zu schreiben, die in JavaScript vorkommen.

Der nicht ganz so einfache Umgang mit Open Source

heise Developer: Wie sieht es in eurem Projekt mit der Verwendung von Open Source aus?

Erich Gamma: In den vier Jahren bei Microsoft hat sich bezüglich des Einsatzes von Open-Source-Projekten extrem viel verändert. Microsoft setzt jetzt nicht nur Open Source ein, sondern arbeitet auch maßgeblich an quelloffenen Projekten mit oder entwickelt Projekte gleich als Open Source. In unserem Projekt verwenden wir zum Beispiel eine Vielzahl von Node.js-Modulen und Electron von GitHub. Allerdings sind wir auch an den Open-Source-Projekten für OmniSharp und TypeScript aktiv beteiligt.

Wie man OpenSource am besten in einem Unternehmen wie Microsoft einsetzt, ist aber immer noch nicht trivial. Es braucht ein Inventar der verwendeten Komponenten und deren Versionen, die sich laufend ändern. Dazu müssen auch Auflagen der Lizenzen wie GPL honoriert werden. Das ist bereits anspruchsvoll, wenn man einmal pro Jahr eine neue Version ausliefert. Für Visual Studio Code machen wir aber alle vier Wochen eine neue Version und müssen diesen Anforderungen trotzdem gerecht werden.

heise Developer: Sei es Eclipse, JUnit, Rational TeamConcert oder VS Code: Betrachtet man deine Karriere, hast du eigentlich ziemlich durchgängig immer an Hilfsmitteln für Entwickler gearbeitet. Was motiviert dich dabei besonders?

Erich Gamma: Als Programmierer verbringt man sehr viel Zeit mit oder in Tools. Wenn ich jetzt die Tools baue mit denen ich viel Zeit verbringe, dann lebt man quasi in dem, was man selbst baut. Das macht Spaß. Außerdem gibt einem das "Eat your own dog food"-Prinzip laufend Feedback und Ideen, wie man die Tools verbessern könnte. Schließlich ist auch die Zusammenarbeit mit Entwicklern, die ein Tool verwenden, spannend. Man kriegt immer viel Fan-Post als Bug Reports, Verbesserungsvorschlag oder einfach Kommentare via Twitter. Ich liebe die Tool-Entwicklung einfach immer noch.

heise Developer: Vielen Dank, dass du dir die Zeit für das Interview genommen hast.

Das Interview führten Julia Schmidt und Alexander Neumann, Redakteure bei heise Developer, während der Enterprise-JavaScript-Konferenz enterJS. (jul [4])

URL dieses Artikels:
https://www.heise.de/-2750465

Links in diesem Artikel:
[1] http://awards.acm.org/award_winners/gamma_2579548.cfm
[2] http://electron.atom.io/
[3] http://www.omnisharp.net/
[4] mailto:jul@heise.de

Copyright © 2015 Heise Medien