Developer Experience: Glückliche Entwickler schreiben besseren Code
(Bild: Pasuwan/shutterstock.com)
Developer Experience umfasst, was Entwickler zufriedener macht. Was zeichnet sie laut aktueller Forschung aus, und was zählt in den Augen eines Entwicklers?
Vielen ist sicherlich der Begriff User Experience (UX) bekannt – er beschreibt die Erfahrung von Benutzerinnen und Benutzern während der Verwendung einer Software. Der Begriff Developer Experience (DX) ist dagegen weniger geläufig. Er adaptiert Konzepte aus der UX-Optimierung auf die Erfahrungen von Entwicklerinnen und Entwicklern. Dieser Artikel stellt das Konzept der Developer Experience vor und beschreibt dann aus der subjektiven Sicht eines JavaScript-Entwicklers, wie sie sich konkret verbessern lässt.
Akademische Definition: Developer Experience
Die Informatiker Fabian Fagerholm und Jürgen Münch von der Universität Helsinki definieren Developer Experience als Erfahrungen mit allen Arten von Artefakten und Aktivitäten [8], denen Entwicklerinnen und Entwickler im Rahmen der Softwareentwicklung begegnen. Sie lassen sich grob unterteilen in Erfahrungen bezüglich der Entwicklungsinfrastruktur, die gefühlsmäßige Einstellung zur Arbeit und den Wert des eigenen Beitrags.
Was die Autoren damit meinen, zeigt Abbildung 1. Hinsichtlich der Infrastruktur zählen Entwicklungs- und Management-Tools, Programmiersprachen, Bibliotheken, Plattformen und Methoden. Wie Entwicklerinnen und Entwickler gefühlsmäßig zu ihrer Arbeit stehen, hängt beispielsweise ab von Respekt, Verbundenheit oder Zugehörigkeit. Den Wert des eigenen Beitrags messen die Autoren am Grad der Übereinstimmung der eigenen Ziele mit denen des Projekts und ihrem persönlichen Engagement.
Der folgende Beitrag bezieht sich hauptsächlich auf den Aspekt der Infrastruktur, in den Augen des Autors sind die verfügbare Infrastruktur und der Umgang damit bei vielen Projekten grundlegend für eine gute oder schlechte Erfahrung bei der Entwicklung. Da der Autor vorrangig als JavaScript- und TypeScript-Entwickler arbeitet, stehen diese Programmiersprachen auch im Zentrum der folgenden Überlegungen. Durch den subjektiven Charakter seiner Ausführungen möchte er andere Entwickler und Entwicklerinnen zum Nachdenken über ihre eigene Developer Experience anregen.
Entwicklerzufriedenheit durch Minimierung der Zeiträuber
In Bezug auf die genutzte Entwicklungsinfrastruktur kann man von einer guten Developer Experience sprechen, wenn Entwicklerinnen und Entwickler beim täglichen Umgang mit ihren Werkzeugen Spaß haben und zufrieden sind. Als zeitraubend empfundene Faktoren des alltäglichen Arbeitens sollten minimal ausfallen. Eine gute Developer Experience führt zu mehr Zufriedenheit beim Arbeiten und auf die Qualität der entwickelten Software auswirken.
Der Begriff "Werkzeug" ist in diesem Falle weit gefasst. Es kann sich hier um das genutzte Betriebssystem, die Programmiersprache, ein spezielles Programm zum Entwickeln von Software wie einen Editor, eine IDE (Integrated Development Environment), die Schnittstelle zu einer Bibliothek oder eine API-Dokumentation handeln.
Ob und wie sich eine gute Developer Experience erreichen lässt, hängt von verschiedenen Faktoren ab, nämlich von der genutzten Programmiersprache, der zur Verfügung stehenden Hardware, der zur Entwicklung genutzten Entwicklungsumgebung, der Verfügbarkeit einer Dokumentation, der Geschwindigkeit der technischen und der produktbezogenen Feedbackschleife und auch von dem organisatorischen Umfeld. Hierbei gilt es zu bedenken: Je populärer eine Programmiersprache ist, desto größer ist das Angebot im Ökosystem bezüglich des Toolings, der Dokumentation und der Bibliotheken.
Veraltete oder dem Entwicklungsauftrag nicht mehr angemessene Hardware verlangsamt den Prozess. Einige Tools bieten mehr Komfortfunktionen als andere, und außerdem spielt die Erfahrung, die Entwicklerinnen und Entwickler bereits mit dem Tool haben, eine Rolle. Da die Geschmäcker und Prioritäten der Menschen unterschiedlich sind, ist ein Begriff wie Developer Experience jedenfalls subjektiv geprägt.
Was bedeutet eine gute Developer Experience für mich?
Für mich persönlich bedeutet eine gute Developer Experience hauptsächlich, stets möglichst schnelle Feedbackschleifen zu haben – also bei allem, was ich tue, möglichst früh Rückmeldung zu bekommen, ob das Getane in Ordnung ist.
Auf technischer Ebene bedeutet das das schnellstmögliche Widerspiegeln der programmierten Änderungen in der laufenden Software. Dadurch kommen mögliche Unstimmigkeiten rasch ans Licht. Je kleiner der Zeitraum ist, der zwischen dem Einbauen und dem Erkennen eines Fehlers liegt, desto besser. Idealerweise weist die IDE ihre Nutzer direkt beim Tippen auf Fehler hin, beispielsweise durch einen eingebundenen Linter. An zweiter Stelle zu nennen sind Ungereimtheiten, die beim Kompilieren zutage treten. Das erlaubt immer noch ein direktes Reagieren, bevor die Anwendung überhaupt gestartet ist. Fehler, die wiederum erst zur Laufzeit der Applikation auffallen, haben die langsamste Feedbackschleife.
Auf organisatorischer Ebene bedeutet das im Idealfall ein frühzeitiges und häufiges Feedback der Endnutzer der Anwendung. So können sie stets auf die tatsächlichen Anforderungen der Kunden eingehen und frühzeitig auf Änderungen reagieren. In der Praxis hat mir frühes und häufiges Fragen nach Feedback schon oft dabei geholfen, schneller zu dem von Kunden gewünschten Ergebnis zu kommen. Ein Beispiel: Bei der Implementierung einer React-Komponente sah die Spezifikation ein Eingabefeld mit besonders komplexer Validierungslogik vor. Es stellte sich aber heraus, dass der Kunde dieses Feld gar nicht brauchte. Hätte ich nicht nach der Implementierung des Minimal-Prototyps um Feedback gebeten, so hätte ich viel Zeit für die Entwicklung der gar nicht benötigten Validierung verschwendet.
Mit dem Code experimentieren und Fehler finden
Zu einer guten Developer Experience gehört für mich außerdem, dass es einfach ist, in und mit dem existierenden Code zu experimentieren. Auch das läuft auf eine höhere Geschwindigkeit der Feedbackschleife hinaus, da für Experimente nicht zwingend erst wieder ein neues Projekt aufzusetzen ist.
Des Weiteren ist es wichtig, dass sich die Suche nach Fehlern so einfach wie möglich gestaltet (das tatsächliche Auffinden ist wiederum ein anderes Thema). Das bedeutet, dass die Anwendung einfach zu debuggen und während der Laufzeit zu untersuchen sein sollte.
Ich möchte möglichst effizient arbeiten und es vermeiden, Zeit mit repetitiven Aufgaben zu vergeuden. Deshalb zählen für mich auch eine gute Autocomplete-Funktionalität und andere Convenience-Features, die viele moderne IDEs mit sich bringen, zu einer guten Developer Experience. Es gehört ebenfalls dazu, sich als professioneller Softwareentwickler oder -entwicklerin an den gegebenen Werkzeugen zu bedienen, also die oben genannten Features tatsächlich effizient zu nutzen.
Der letzte wichtige Punkt für eine gute Developer Experience ist, dass man so wenig Zeit wie möglich für die eher “nervigen” Teile des Programmierens aufwenden muss. Dazu zählen die Formatierung des Quellcodes, Aufräumarbeiten wie das Entfernen ungenutzter Variablen und das Organisieren von Import-Befehlen sowie das Projekt-Setup und die Konfiguration. Die Formatierung und die Aufräumarbeiten sollten idealerweise vollständig automatisiert ablaufen, das Projekt-Setup und das Konfigurieren sind soweit wie möglich durch sinnvolle und direkt nutzbare Standardwerte zu verkürzen.
Geschicktes Auswählen der Programmiersprache
Während sich auf der organisatorischen Ebene allein durch die Wahl des Toolings nur wenig erreichen lässt, können Entwicklerinnen und Entwickler sich in den anderen oben genannten Punkten mit gutem Werkzeug und der Wahl einer geeigneten Programmiersprache durchaus selbst zu einer besseren Developer Experience verhelfen.
Im JavaScript- und TypeScript-Ökosystem gibt es einige Ansatzpunkte, um sich das Leben ein bisschen zu erleichtern, wie beispielsweise die Nutzung von TypeScript anstelle von JavaScript [9]. Die durch TypeScript sichergestellte Typsicherheit und die IDE- und Editor-Unterstützung durch Visual Studio Code [10] oder WebStorm [11] beschleunigen die Feedbackschleife. Viele JavaScript-typische Fehler wie der Attributzugriff auf einen undefined- beziehungsweise null-Wert lassen sich direkt beim Tippen oder Kompilieren erkennen und frühzeitig beheben.
Feedbackschleife beschleunigen
Auch die Verwendung eines Live-Reload-Tools beschleunigt die Feedbackschleife. Es erkennt alle Änderungen am Quellcode automatisch und startet die Anwendung selbstständig neu, sodass die Änderungen direkt in der neu gestarteten Anwendung widergespiegelt sind. Live-Reload-Tools gibt es für browserseitige Anwendungen sowie für serverseitige Anwendungen. Außerdem ist in vielen Testframeworks wie beispielsweise jest [12] oder mocha eine Live-Reload-Funktion eingebaut [13]. Bei der browserseitigen Anwendungsentwicklung bedeutet ein Live Reload, dass sich die im Browser geöffnete Website automatisch aktualisiert, sobald eine Datei mit Änderungen gespeichert wird. Dadurch lassen sich Änderungen direkt auf der Website visualisieren. Bei serverseitiger Entwicklung startet sich die laufende Anwendung automatisch neu, wenn eine Datei verändert wird. So lassen sich unter anderem neu hinzugekommene Endpunkte direkt über ein API-Client-Tool wie Insomnia [14] oder Postman [15] testen.
Um schnell mit dem existierenden Code zu experimentieren, eignen sich die Chrome-Entwicklerkonsole und die Node REPL (read–eval–print loop). Beide sind einfach und schnell zugänglich: Das Öffnen der Node REPL erfolgt über den Befehl node in der Kommandozeile, das Öffnen der Chrome Developer Console über den systemabhängigen Shortcut wie beispielsweise Strg + Shift + J unter Windows. Beide Tools sind nützlich, um kleine Experimente oder Scripts auszuprobieren, ohne gleich neue Dateien oder Projekte erstellen zu müssen.
Die Anwendung anhalten durch Breakpoints
Auch die Nutzung eines Debuggers kann die Feedbackschleife beschleunigen, da er das Anhalten der Anwendung an beliebiger Stelle durch die Nutzung von Breakpoints erlaubt. Des Weiteren ermöglicht er das Untersuchen des Anwendungszustands und der im Quellcode gesetzten Variablen zur Laufzeit. Durch die Kombination eines Debuggers und der oben genannten Entwicklerkonsole lassen sich außerdem Experimente oder Skripte auf zur Laufzeit gesetzten Variablen ausführen. Für serverseitige Anwendungen kommen beispielsweise Visual Studio Code oder WebStorm als IDE mit eingebautem Debugger in Frage. Für browserseitige Anwendungen bieten alle gängigen Browser wie Chrome oder Firefox einen eingebauten Debugger an.
Um den Anteil der ungeliebten Routineaufgaben beim Programmieren so gering wie möglich zu halten, kommen außerdem Tools für automatisierte Formatierung und automatisiertes Linting in Betracht. Ein Linter sorgt automatisch dafür, dass gewisse Formatierungs- und Code-Style-Regeln wie eine Einrückung oder maximale Zeilenbreite eingehalten werden. Er untersucht und analysiert Code, um auf potenzielle Fehler oder Unreinheiten ("unclean code") aufmerksam zu machen und bezieht sich dabei immer auf einen Satz an vorgegebenen Regeln, die er beachtet. Zwei Beispiele für solche Regeln wären: “Es darf kein Code in einer Quelldatei vorhanden sein, der nie erreicht werden kann” oder “Es muss immer === anstelle von == bei Vergleichen genutzt werden”.
Ein beliebtes Code-Formatierungstool im JavaScript-Ökosystem ist Prettier [16]: Es ist mit Standardregeln vorkonfiguriert, die Konfiguration lässt sich aber auch beliebig anpassen. Der De-facto-Standard für Linting im JS-Universum ist ESLint [17]. Wie Prettier kennt es viele Standardregeln und verfügt für verschiedene Projektarten über einen Satz an projektspezifischen Zusatzregeln. Auch hier lassen sich die Einstellungen beliebig verändern.
Weitere Zeitfresser in den Griff bekommen
Ein weiterer zeitaufwändiger Arbeitsschritt ist das initiale Projekt-Setup einer neuen Anwendung. Oft gilt es, Compiler oder Build- beziehungsweise Bundling-Tools wie webpack [18] oder Rollup [19] zu konfigurieren, Pakete, von denen die Anwendung abhängig ist, zu installieren, den Quellcode in einer vorgegebenen Ordnerstruktur zu strukturieren oder eine Testumgebung mit jest beziehungsweise mocha einzurichten. Dieses Projekt-Setup wird auch als “Scaffolding” bezeichnet. Um sich hierbei Zeit zu sparen, stehen Scaffolding-Tools zur Nutzung bereit. Sie nehmen einem viele der oben beschriebenen Arbeitsschritte ab und liefern nach der Ausführung eine fertig eingerichtete Applikation ab, die als Grundlage für die weitere Entwicklung dienen kann. Sowohl im browserseitigen als auch im serverseitigen Anwendungsbereich bringen viele Libraries eigene Scaffolding-Tools mit.
So besitzen Browserbereich die Frameworks Angular [20], Vue [21] und React [22] eigene Command-Line Interfaces (CLI) für das Scaffolding. Auf der Serverseite helfen Scaffolding-Tools wie das NestJS CLI von NestJS [23] oder das AWS CDK CLI von AWS [24]. Zudem gibt es das Library-übergreifende Scaffolding-Tool yeoman [25], das es Nutzern erlaubt, ihre eigenen Blaupausen für Scaffolding zu erstellen und mit der Community zu teilen. Hinsichtlich des aktuellen JavaScript- und TypeScript-Ökosystems fällt auf, dass immer mehr Projekte Wert auf Developer Experience im Sinne der oben genannten Punkte legen.
Einige Bibliotheken und Tools bieten außerdem einen (almost-)zero-config-Ansatz – sie sind also ohne (oder mit ein wenig) Konfigurationsaufwand direkt einsetzbar. Ein solches Tool, das es Entwicklerinnen und Entwicklern erlaubt, mit einer guten Developer Experience TypeScript-Libraries zu erstellen [26], ist tsdx. Ähnliche Werkzeuge sind @pika/pack oder Neutrino: @pika/pack ist ein Werkzeug [27], um komfortabel npm-Bibliotheken zu erstellen, während es sich bei Neutrino um ein Tool handelt, das mit vorgefertigten webpack-Konfigurationen Webanwendungen erstellt [28]. Alle aufgezählten Werkzeuge bieten einen zero-config-Ansatz und versprechen dadurch eine verbesserte Developer Experience.
Beispielanwendung: Umsetzung anhand einer TypeScript- und Node.js-Applikation
Die oben genannten Punkte können Entwicklerinnen und Entwickler aber auch ohne größeren Aufwand und ohne die Nutzung eines zero-config-Tools in existierende JavaScript- und TypeScript-Projekte einführen oder direkt beim Aufsetzen eines neuen Projekts berücksichtigen.
Das folgende Beispiel nutzt die JavaScript-Runtime Node.js [29] und das Webapplikationsframework express [30], um eine serverseitige Anwendung mit TypeScript zu bauen. Es veranschaulicht, wie man ein solches Projekt von Grund auf aufsetzt und dabei auch Tools und Einstellungen nutzt, um die Grundlage für eine angenehme Developer Experience zu schaffen.
Um das folgende Beispiel erfolgreich zu implementieren, sollten die JavaScript-Runtime node und der Package Manager yarn [31] bereits installiert sein. Zu Beginn ist ein Ordner anzulegen und dort mit yarn ein neues Projekt zu erstellen:
mkdir developer-experience-node-ts
cd developer-experience-node-ts
yarn init
Als “entry point” gibt das Beispiel src/index.ts an. Dieser Aufruf erstellt eine package.json, die ähnlich aussehen wird wie folgt:
{
"compilerOptions": {
"module": "commonjs",
"target": "es6",
"rootDir": "./src",
"outDir": "./build",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true
}
}
Nun wird eine Datei mit dem Namen tsconfig.json und folgendem Inhalt erstellt:
{
"name": "developer-experience-node-ts",
"version": "1.0.0",
"main": "src/index.ts",
"author": "Felix Magnus",
"license": "MIT"
}
Das Webapplikationsframework express und die dazugehörigen Typdefinitionen für node und express lassen sich mit folgenden Befehlen installieren: yarn add express sowie yarn add -D @types/node @types/express.
Danach ist eine index.ts-Datei an dem Ort zu erstellen, der bei dem yarn init-Aufruf als Einstiegspunkt (entryPoint) angegeben ist – in der Beispielanwendung also src/index.ts. Exemplarischer Anwendungs-Code, der sich in die index.ts einfügen lässt, steht im folgenden Listing:
import express from "express"
const PORT = 8000
const app = express()
app.get("/", (_, res) => res.send("Juhu, Developer Experience!"))
app.listen(PORT, () => {
console.log(`[server]: Server is running at https://localhost:${PORT}`)
})
Jetzt erhält die package.json-Datei zusätzlich eine scripts-Property, in die folgendes Skript zum Starten der Anwendung einzufügen ist:
"scripts": {
"start": "ts-node src/index.ts"
}
Zum Starten der Anwendung lässt sich der Befehl yarn start nutzen.
Setup des Beispielprojekts: Mission completed
Damit steht das Standard-Setup des Beispielprojekts. Abgesehen von der Nutzung von TypeScript ist damit allerdings noch nicht viel in Richtung Developer Experience unternommen – im nächsten Schritt ändert sich das. Hierzu gilt es zunächst, Prettier als automatischen Codeformatierer hinzuzufügen: yarn add -D prettier
Danach wird die Konfigurationsdatei für prettier mit dem namen .prettierrc und dem folgenden Inhalt erstellt:
{
"semi": false,
"tabWidth": 4,
"proseWrap": "never",
"printWidth": 100,
"trailingComma": "none"
}
(Hinweis: Die angegebenen Werte sind die, mit denen der Autor persönlich gerne arbeitet – sie lassen sich nach Belieben ändern.)
Neben automatischer Formatierung ist auch automatisches Erkennen und Beheben von Fehlern und anderen Ungereimtheiten (Linting) wünschenswert, hierfür wird in diesem Beispielprojekt ESLint genutzt. ESLint und die nötigen Plug-ins werden mit der folgenden CLI-Eingabe installiert: yarn add -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin.
Auch ESLint benötigt eine Konfigurationsdatei, in der die genutzten Regeln festzulegen sind. Sie trägt den Namen .eslintrc und hat den folgenden Inhalt:
{
"root": true,
"parser": "@typescript-eslint/parser",
"plugins": ["@typescript-eslint"],
"extends": [
"eslint:recommended",
"plugin:@typescript-eslint/eslint-recommended",
"plugin:@typescript-eslint/recommended"
]
}
Neben der Regel erlaubt ESLint außerdem die Angabe, welche Dateien es in der Untersuchung nicht berücksichtigen soll. Hierfür wird eine Datei mit dem Namen .eslintignore benötigt. Der Inhalt lautet wie folgt:
build
node_modules
Die package.json ist nun um zwei Skripte zu erweitern, die jeweils den Codeformatierer und den Linter ausführen:
"scripts": {
// ...
"prettier": "prettier --write src/**/*.ts",
"lint": "eslint -c .eslintrc --ext ts src",
// ...
}
Um den Code nach den Regeln zu formatieren, die in der .prettierrc-Datei definiert sind, lässt sich der Aufruf yarn prettier nutzen. Außerdem kann man yarn lint aufrufen, um den Code manuell auf Fehler zu überprüfen. Der Aufruf yarn lint --fix versucht, alle Linting-Probleme im Code automatisch zu beheben. Alle Probleme, die danach weiterhin in der Ausgabe stehen, lassen sich nicht automatisch beheben – sie müssen von Hand behoben werden (s. Abb. 2).
Um die Developer Experience weiter zu verbessern, empfiehlt es sich, sowohl Prettier als auch ESLint direkt in die IDE zu integrieren. Das bedeutet, dass die IDE die geöffneten Dateien bei jedem Speichervorgang automatisch formatiert und auf Fehler überprüft und diese, wenn möglich, direkt behebt. Das erspart den Aufwand, häufig manuell yarn lint und yarn prettier aufrufen zu müssen.
Um Prettier und ESLint in Visual Studio Code zu konfigurieren, sind zunächst die Prettier- und ESLint- Erweiterungen zu installieren. Danach wird in dem Beispielprojekt ein neuer Ordner namens .vscode erstellt. Hierfür ist eine Datei mit dem Namen settings.json und dem folgenden Inhalt notwendig (s. auch Abb. 3):
{
"[typescript]": {
// Prettier
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,
// ESLint
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
}
}
}
Um das Gleiche in WebStorm oder anderen IDEs von JetBrains zu konfigurieren, gibt es Anleitungen zu Prettier [32] und zu ESLint [33].
Automatischer Reload erkennt Veränderungen an Quellcodedateien
Als Nächstes geht es um das Thema Auto Reload. Wie oben bereits erwähnt, erkennt ein Auto-Reload-Tool Veränderungen an Quellcodedateien, kompiliert daraufhin automatisch erneut den Code und startet die Anwendung neu.
Viele Scaffolding-Tools wie Create React App und Nest.js verfügen bereits über eine eingebaute Live-Reload-Funktion. Um ein solches Auto-Reload-Feature in unserer einfachen NodeJS- und Express-Anwendung einzurichten, kommt das Tool nodemon zum Einsatz [34]. Es lässt sich über den folgenden Befehl installieren: yarn add -D nodemon
In Anlehnung an das Skript, das die Applikation startet, wird der Datei package.json nun ein weiteres start:watch-Skript hinzugefügt, das die Anwendung inklusive Live-Reload-Tool nodemon startet:
"scripts": {
// ...
"start:watch": "nodemon src/index.ts",
// ...
}
nodemon erkennt automatisch, dass es in dem Projekt um TypeScript-Dateien geht und verwendet das zuvor installierte ts-node (anstelle des sonst üblichen node), um den Code auszuführen. Nun ist der Befehl yarn start:watch bereit, die Applikation zu starten. Im Gegensatz zu dem vorher definierten yarn start überwacht nodemon hier sämtliche Dateiänderungen und startet die Applikation automatisch neu, wie Abbildung 4 veranschaulicht.
Damit sind wir am Ende der Developer-Experience-Optimierung für das Beispielprojekt angekommen. Einige Scaffolding-CLIs, die bei Libraries wie React oder NestJS mit ausgeliefert werden, setzen viele der hier im Beispiel händisch durchgeführten Konfigurationen wie Linting und Live Reload automatisch mit auf. Das bedeutet, dass man beim Setup eines Projektes mit der Library Nest.JS und dem zugehörigen NestJS-CLI letztlich mit weniger Konfigurationsaufwand zum selben Ergebnis kommt, wie das Beispiel hoffentlich zeigen konnte. Falls also eine Library zum Einsatz kommen soll, die über ein eigenes Scaffolding-Tool in Form eines Command-Line Interfaces verfügt, empfiehlt sich alternativ durchaus die Nutzung dieses CLI.
Spaß an der Arbeit sorgt für besseren Code
Die Developer Experience ist ein wichtiger Faktor, der bei der Softwareentwicklung Berücksichtigung finden sollte. Auf der technischen Seite können schon kleine Verbesserungen den Spaß an der Arbeit und somit die Produktivität, aber auch die Qualität und Sicherheit der Ergebnisse deutlich erhöhen. Viele Scaffolding-Tools im Ökosystem von JavaScript und TypeScript bieten von Haus aus einige Vorzüge wie Linting, Code Formatting und Live Reloading an, aber auch bei von Hand aufgesetzten Projekten lassen sich mit wenig Konfigurationsaufwand schnell gute Ergebnisse erzielen.
Felix Magnus
arbeitet seit 2019 als IT-Consultant bei codecentric. Sein Schwerpunkt liegt im Bereich der Fullstack-Webentwicklung. Des Weiteren interessieren ihn Themen wie Continuous Integration/Continuous Delivery (CI/CD), Cloud Native und DevOps.
(sih [35])
URL dieses Artikels:
https://www.heise.de/-6150890
Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/KI-in-DevSecOps-Vom-Copiloten-zum-Autopiloten-9640331.html
[2] https://www.heise.de/hintergrund/Chancen-fuer-Quereinsteiger-wie-IT-Neulinge-und-erste-Projekte-zusammenfinden-9590255.html
[3] https://www.heise.de/news/We-Are-Developers-Das-Herbstmagazin-2023-kostenlos-herunterladen-9570659.html
[4] https://www.heise.de/hintergrund/Praktische-Barrierefreiheit-in-der-Webentwicklung-9279097.html
[5] https://www.heise.de/news/We-Are-Developers-Die-englische-Ausgabe-2023-ist-kostenfrei-verfuegbar-9201013.html
[6] https://www.heise.de/hintergrund/Webentwicklung-Detaillierte-Linkvorschauen-von-Websites-automatisiert-erstellen-7770614.html
[7] https://www.heise.de/developer/young-professionals-6065678.html
[8] https://helda.helsinki.fi//bitstream/handle/10138/37576/icssp2012.pdf
[9] https://www.typescriptlang.org/
[10] https://code.visualstudio.com/
[11] https://www.jetbrains.com/de-de/webstorm/
[12] https://jestjs.io/
[13] https://mochajs.org/
[14] https://insomnia.rest/
[15] https://www.postman.com/
[16] https://prettier.io/
[17] https://eslint.org/
[18] https://webpack.js.org/
[19] https://rollupjs.org/
[20] https://angular.io/
[21] https://vuejs.org/
[22] https://reactjs.org/
[23] https://nestjs.com/
[24] https://docs.aws.amazon.com/cdk/latest/guide/cli.html
[25] https://yeoman.io/
[26] https://github.com/formium/tsdx
[27] https://www.pika.dev/blog/introducing-pika-pack/
[28] https://neutrinojs.org/
[29] https://nodejs.org/
[30] https://expressjs.com/de/
[31] https://yarnpkg.com/
[32] https://www.jetbrains.com/help/idea/prettier.html#ws_prettier_reformat_code
[33] https://stackoverflow.com/questions/38883634/how-can-i-run-eslint-fix-on-my-javascript-in-intellij-idea-webstorm-other-je
[34] https://github.com/remy/nodemon
[35] mailto:sih@ix.de
Copyright © 2021 Heise Medien