Developer Experience¹ ist ein Begriff² mit einer selbsterklärenden Bedeutung – die Erfahrung von Entwicklern – aber er entzieht sich einer Definition in dem Sinne, dass Menschen ihn zu verschiedenen Zeiten aus unterschiedlichen Gründen und in Bezug auf unterschiedliche Dinge verwenden. Zum Beispiel ist der aktuelle Jobtitel unserer Sarah Drasner „VP of Developer Experience“ bei Netlify, also ist es eine sehr reale Sache. Aber ein Jobtitel ist nur eine Art, wie der Begriff verwendet wird. Lassen Sie uns ein wenig eintauchen und ihn auf die verschiedenen Arten anwenden, wie Menschen über den Begriff denken und ihn verwenden.
Menschen denken an spezifische Unternehmen.
Ich höre DX und Stripe oft zusammen. Das ergibt Sinn. Stripe ist ein Zahlungs-Gateway-Unternehmen, das sich fast ausschließlich an Entwickler richtet. Sie legen großen Wert darauf, ihren Kunden (Entwicklern) eine gute Erfahrung zu bieten, daher „Developer Experience“. Hören Sie sich einfach Suz Hinton an, wie sie über „Friction Journals“ spricht, was die Idee ist, sich hinzusetzen, ein Produkt (wie Stripe) zu benutzen und jeden kleinen WTF-Moment, jede Verwirrung und Frustration zu notieren, damit Verbesserungen vorgenommen werden können.
Netlify ist in dieser Hinsicht wie Stripe, ebenso wie Heroku, CodePen und eine beliebige Anzahl von Unternehmen, bei denen die gesamte Kundenbasis aus Entwicklern besteht. Für solche Unternehmen ist DX fast so etwas wie UX (User Experience) für jedes andere Unternehmen ist.
Menschen denken an spezifische Technologien.
Es ist üblich, dass DX im Zusammenhang mit dem Vergleich von Technologien erwähnt wird. Zum Beispiel werden einige Leute sagen, dass Vue eine bessere Developer Experience als React bietet. (Ich versuche nicht, etwas anzuzetteln, ich habe nicht einmal eine starke Meinung dazu.) Sie sprechen über Dinge wie APIs. Vielleicht ist das **State** in einer der beiden intuitiver zu verwalten als in der anderen. Oder sie sprechen über Features. Ich weiß, dass Vue und Svelte integrierte Animationshelfer haben, während React keine hat. Aber React hat Hooks und die Leute mögen sie im Allgemeinen. Das sind Aspekte der DX dieser Technologien.
Oder sie sprechen vielleicht über das Gefühl rund um die Tools, die die Kerntechnologie umgeben. Ich weiß, dass create-react-app weithin beliebt ist, aber das gilt auch für die Vue CLI. React Router ist sehr beliebt, aber Vue hat einen Router, der vom Kernteam gesegnet (und gepflegt) wird, was ein gewisses Gefühl von Vertrauen vermittelt.
> vue create hello-world> npx create-react-app my-appIch verwende JavaScript-Frameworks/-Bibliotheken nicht nur als zufälliges Beispiel. Ich höre Leute mehr über DX im Zusammenhang mit JavaScript sprechen als über alles andere – das könnte daran liegen, dass Leute in meinen Kreisen so denken, aber es scheint bemerkenswert.
Menschen denken an die Welt um die Technologie herum.
Jeder denkt, gute Dokumentationen seien wichtig. Es gibt keine Technologie, die besser ist als eine andere, aber eine viel schlechtere Dokumentation hat. Die mit der besseren Dokumentation ist insgesamt besser, weil sie eine bessere Dokumentation hat. Das ist nicht die Technologie selbst; das ist die Welt um sie herum.
Haben Sie jemals ein Entwicklerprodukt mit einer API gesehen, und wenn Sie die Dokumentation für die API aufrufen, während Sie angemeldet sind, werden API-Schlüssel und Daten und Einstellungen aus Ihrem eigenen Konto zur Demonstration verwendet? Das ist für mich außergewöhnlich. Das fühlt sich für mich nach DX an.
„Machen Sie das Richtige einfach“, merkt Jake Dohm an.
Dieses Wort, einfach, scheint stark mit DX verbunden zu sein. Technologien, die Dinge einfach machen, sind Technologien mit guter DX. Sowohl in der Anwendung als auch im Verständnis. Wie einfach (und schnell) kann ich verstehen, was Ihre Technologie tut und was ich damit machen kann?
Was die Technologie tut, ist oft nur die Hälfte der Geschichte. Der „Happy Path“ mag großartig sein, aber was passiert, wenn sie kaputtgeht oder Fehler auftreten? Wie sind die Fehlerberichterstattung und das Logging? Ich denke dabei an Apollo und GraphQL in meiner eigenen Erfahrung. Es ist eine großartige Technologie, aber die Fehlerberichterstattung fühlt sich schrecklich an, da es sehr schwierig ist, selbst Tippfehler zu verfolgen, die Fehler in der Entwicklung auslösen.
Wie sieht die Debugging-Geschichte aus? Gibt es spezielle Werkzeuge dafür? Dasselbe gilt für das Testen. Diese Dinge sind grundlegende DX-Themen.
Menschen denken an Technologie angebote.
Zum Beispiel mag eine Technologie bereits „gut“ sein. Sagen wir, sie hat eine API, die Entwickler mögen. Dann bietet sie eine CLI an. Das ist (im Allgemeinen) eine DX-Verbesserung, weil es Türen für Entwickler öffnet, die lieber in dieser Welt arbeiten und Prozesse darum herum aufbauen.
Ich denke hier an Dinge wie Netlify Dev. Sie haben bereits diese großartige Plattform und sagen dann: Hier, Sie können sie auch alle auf Ihrem eigenen Rechner ausführen. Das bedeutet, DX ernst zu nehmen.
netlify devDas Vorhandensein einer dedizierten CLI ist fast immer ein guter DX-Schritt, vorausgesetzt, sie ist gut gemacht und wird gepflegt. Ich erinnere mich an WordPress vor WP-CLI, und jetzt wird in vielen Dokumentationen einfach davon ausgegangen, dass Sie es verwenden. Ich war nicht einmal bewusst, dass Cloudinary eine CLI hat, bis neulich, als ich sie brauchte und angenehm überrascht war, dass sie existiert. Ich erinnere mich, als npm-Skripte die Welt eroberten. (Was wäre npm ohne CLI?) Wir hatten früher eine Vielzahl verschiedener Task-Runner, aber jetzt wird weitgehend davon ausgegangen, dass ein Projekt in package.json integrierte Run-Befehle hat, die Sie verwenden, um alles zu tun, was das Projekt benötigt.
Melanie Sumner denkt sofort an CLIs als Kern-DX.
Menschen denken an die wörtliche Erfahrung des Codens.
Nichts ist direkter DX als die Erfahrung, Code in eine Code-Editor-Software einzugeben und auszuführen. Das ist, was „Codieren“ ist und was Entwickler tun. Es ist kein Wunder, dass Entwickler diese Erfahrung ernst nehmen und ständig versuchen, sie für sich und ihre Teams zu verbessern. Ich denke an Dinge wie VS Code, wie seine DX es in so kurzer Zeit so dominant im Bereich Code-Editoren gemacht hat. VS Code tut viele Dinge, die Entwickler mögen, tut sie gut, tut sie schnell und ermöglicht ein sehr breites Maß an Anpassung.
TypeScript wird weiterhin populärer, zweifellos teilweise aufgrund der Erfahrung, die es innerhalb von VS Code bietet. TypeScript hilft Ihnen buchstäblich, besser zu codieren, indem es Ihnen zum Beispiel anzeigt, welche Parameter Funktionen benötigen und es schwierig macht, das Falsche zu tun.
Dann gibt es die Erfahrung außerhalb des Editors, nämlich im Browser selbst. Vor Jahren habe ich Style Injection is for Winners geschrieben, wo mein Punkt war, dass als CSS-Entwickler die Erfahrung, CSS-Code zu speichern und die Änderungen sofort im Browser zu sehen, eine DX ist, die man definitiv haben möchte. Dieses Konzept lebt weiter und wächst auch in JavaScript, wo „Hot Reloading“ Gänsehaut erzeugt.
Der Unterschied zwischen einer schlechten Entwicklungsumgebung (keine IDE-Hilfe, langsame Speicherungen, manuelle Aktualisierungen, langsame Pipelines) und einer großartigen Entwicklungsumgebung (fancy Editor-Unterstützung, Hot Reloading, alles schnell) ist verblüffend. Eine gute Entwicklungsumgebung, gute DX, macht Sie zu einem besseren und produktiveren Programmierer.
Menschen vergleichen sie mit User Experience (UX).
Es gibt manchmal **eine starke negative Konnotation** zu DX. Es passiert, wenn Menschen sie dafür verantwortlich machen, dass sie existiert, auf Kosten der User Experience.
Ich denke an Dinge wie clientseitige Entwickler-nur-Bibliotheken. Denken Sie an die klassische Bibliothek, über die sich jeder gerne lustig macht: Moment.js. Moment ermöglicht es Ihnen, Daten in JavaScript zu manipulieren, und wird oft clientseitig dazu verwendet. Benutzer kümmern sich nicht darum, ob Sie eine schicke API zur Manipulation von Daten haben. Das ist ausschließlich eine Entwicklerfreundlichkeit. Also liefern Sie diese Bibliothek für sich selbst (gute DX) auf Kosten der Verlangsamung der Website (schlechte UX). Die meisten clientseitigen JavaScript fallen in diese Kategorie.
Genauso oft **verbinden Menschen Developer Experience und User Experience**. Wenn Entwickler befähigt und effektiv sind, wird dies „nach unten sickern“ und zu guter Software führen, so die Theorie.
Im schlimmsten Fall befinden wir uns in einer Situation, in der UX und DX auf einer Wippe stehen. Belasten Sie DX und UX leidet auf der anderen Seite. Im besten Fall finden wir Wege, DX und UX vollständig zu entwirren, Wert in beiden zu finden und beide ernst zu nehmen. Obwohl, wenn eine gewinnen muss, dann sicher die Benutzer. Wie die HTML-Spezifikation besagt
Menschen denken über Zeit nach.
Wie lange dauert es, eine Technologie zu übernehmen? Gute DX berücksichtigt dies. Kann ich sie nutzen, ohne alles neu zu schreiben? Wie schnell kann ich sie hochfahren? Wie gut funktioniert sie mit anderen Technologien, die ich verwende? Was ist mein Zeitaufwand?
Diese Art von Dingen erinnert mich an einige neuere Erfahrungen mit Cloudflare Workers. Es ist eine wirklich coole Technologie, in die wir uns hier nicht vertiefen können, aber genug gesagt, sie gibt Ihnen die Kontrolle über eine Website auf einer hohen Ebene, die wir oft nicht bedenken. Was wäre zum Beispiel, wenn Sie eine Netzwerkanforderung manipulieren könnten, bevor sie überhaupt Ihren Webserver erreicht? Sie müssen sie nicht verwenden, aber aufgrund der Ebene, auf der sie operiert, eröffnen sich neue Türen, ohne sich um die von Ihnen verwendeten Technologien kümmern oder sie beeinträchtigen zu müssen.
Nicht nur die Technologie selbst positioniert sich gut, die DX ihrer Nutzung ist, obwohl es einige Kanten gibt, zumindest gut durchdacht und bietet eine browserbasierte Testumgebung.
Ein mächtiges Werkzeug mit hohen Investitionskosten, na ja, das ist cool. Aber ein mächtiges Werkzeug mit geringen Investitionskosten ist gute DX.
Menschen wollen nicht darüber nachdenken.
Man sagt, die beste Typografie wird unbemerkt bleiben, weil man nur sieht, was die Worte sagen, nicht die Typografie selbst. Das kann auch für Developer Experience gelten. Die beste DX ist, dass Sie die Werkzeuge oder die Technologie nie bemerken, weil sie einfach funktionieren.
Gute DX bedeutet einfach, dass man seinen Job machen kann, anstatt mit Werkzeugen zu kämpfen. Die Werkzeuge könnten Ihre Entwicklungsumgebung sein, es könnten Build-Tools sein, es könnten Hosting-Sachen sein, oder es könnten sogar die APIs sein, mit denen Sie Schnittstellen bilden. Ist die API intuitiv und hilfreich oder obskur und knifflig?
Fühlen Sie sich frei, dies in den Kommentaren weiter zu vertiefen. Was ist DX für Sie?
- Schreiben wir Developer Experience groß? Ich werde es einfach tun.
- Es sieht so aus, als hätte Michael Mahemoff einen guten Anspruch darauf, den Begriff geprägt zu haben.
Nicht um daraus eine Sprachschlacht zu machen, und ich schätze, ich bin voreingenommen, aber wenn es um Developer Experience geht, denke ich nicht, dass Ruby unerwähnt bleiben sollte. Die Sprache wurde um Entwicklerglück herum entworfen. Siehe auch The Rails Doctrine, ein beliebtes Ruby-Framework.
Python hat auch schöne Ideale, aber die Syntax ist so schlecht, dass es ein Witz ist
Ruby ist, soweit ich das gesehen habe, eigentlich nicht viel besser
Für mich hat Shopify die schlechteste DX. Ich bin immer noch schockiert, dass man nicht einmal das HTML-Output minifizieren kann, ganz zu schweigen von der fehlenden Unterstützung für Git zum Beispiel. Das Beste, was wir tun konnten, war die Verwendung von Tools wie Theme Kit, das als Shopifys GitHub präsentiert wird, und das bringt mich zum Weinen, wo man auf die Synchronisierung von lokalem zu Remote-Code warten muss, um Änderungen zu sehen.
Ich könnte mich hier irren und würde es schätzen, wenn jemand Informationen hat, dass ich hier nicht richtig liege.
Menschen vergleichen sie mit User Experience
Hierarchie ist in Ordnung, aber etwas stimmt immer noch nicht... (w3c)
Aus meiner Erfahrung
– Benutzer wissen meistens nicht einmal, wer der Autor ist
– Autoren verstecken sich meist hinter „wir“, „Community“, Team usw.
– Browser-Implementierer hören nicht auf Autoren
– Spezifikationsmacher kümmern sich nicht darum, zu prüfen, ob der Implementierer auf die Autoren hört
weil all das
– App-Autoren hören in erster Linie auf Implementierer
also bekommt man DX statt UX
Mein Punkt ist, dass die Hierarchie befolgt und von ihren Mitgliedern zum Besseren gesteuert werden sollte...
„Im Konfliktfall Benutzer über Autoren über Implementierer über Spezifizierer über theoretische Reinheit berücksichtigen. Mit anderen Worten, Kosten oder Schwierigkeiten für den Benutzer sollten mehr Gewicht haben als Kosten für die Autoren; die wiederum mehr Gewicht haben sollten als Kosten für die Implementierer.“
Das sollte für jedes Produkt gelten, das gut sein soll.
Benutzer ernähren Sie, machen Sie sie glücklich!
Schöner Artikel! Es stimmt, dass wir Entwickler oft unsere „Developer Experience“ zu sehr mit dem vermischen, was wir für die „User Experience“ halten.
Ich denke, das ist ein schwerwiegendes Thema, das wir als Entwickler noch nicht richtig formulieren konnten.
Für den alltäglichen, durchschnittlichen Manager und die Unternehmensleitung hat Developer Experience die geringste Priorität. „Warum, wir bezahlen Sie gut, also seien Sie still und coden Sie“, sagen sie, da es keine harten Zahlen oder tiefen Gedanken darüber gibt, warum ein Unternehmen darin investieren sollte.
Aber Developer Experience ist auch Produktivität, und Produktivität bedeutet normalerweise bare Münze.
Die andere Folge ist die Anpassungsfähigkeit bestimmter Technologien. Zum Beispiel ist es mir nie gelungen, Java zu installieren und ein Repository in Java zu starten, ohne die Fehlermeldungen ausführlich zu googeln. Persönlich würde ich es niemals für meine eigenen Projekte wählen. Vergleichen Sie es mit der einfachen Installation von Node und dem Ausführen von
create-react-app...Die nächste Revolution ist also, DX ernst zu nehmen. Sie wird Sprachen, Plattformen und Infrastrukturen auf- und absteigen lassen.
Nur so zur Info: Ich glaube, wirklich gute DX berücksichtigt immer den Endbenutzer. Wenn etwas an der Developer Experience zu schlechter Leistung führt oder die Benutzeroberfläche unzugänglich macht, ist das eine schreckliche Erfahrung, egal wie „schön“ die Erfahrung des Entwicklers ist. Gute DX sollte das „Richtige“ zum Standard oder extrem einfach machen und das „Falsche“ schwierig oder unmöglich machen, und ich denke, wir als Entwickler sollten uns nicht mit weniger zufriedengeben.