Nicht nur Code bestimmt die Softwarequalität, sondern auch die Art, wie Softwareentwicklerinnen und -entwickler ihn dokumentieren und präsentieren. In einer Zeit, in der viele Entwicklerteams vollständig remote arbeiten und die Codebase weiter kontinuierlich wächst, ist die konsistente und automatisierte Qualitätskontrolle eine Notwendigkeit.

Während meiner Arbeit an einem node-basierten Dokumentationsstack mit dem Static-Site-Generator Astro und Starlight, einem darauf aufbauenden Framework speziell für Dokumentationswebsites, bin ich auf die Herausforderung gestoßen, nicht nur sauberen Code, sondern auch hochwertige Prosa zu produzieren. Prosa kommt aus dem Lateinischen und bedeutet „geradeheraus reden“ – also ohne Schnörkel normal sprechen.

Im Rahmen einer Dokumentation bezeichnet Prosa den gesamten ausformulierten Textinhalt der technischen Dokumentation – alle Erklärungen, Anleitungen, Beschreibungen und Kommentare. Ziel ist es, dass Stil-Konsistenz, Grammatik, Wortwahl, Lesbarkeit und die Einhaltung von Dokumentationsrichtlinien sichergestellt sind und die technische Dokumentation nicht nur funktional korrekt, sondern auch verständlich, einheitlich und professionell geschrieben ist.

Die Lösung: Ein mehrstufiges Linting-System, das Code-Qualität, Formatierung und Prosa-Linting für englischsprachige Dokumentation geschickt miteinander verbindet und sich durch Git Pre-Commit Hooks sowie CI/CD-Pipelines automatisieren lässt. Prosa Linting für deutsche Texte ist nicht nativ integriert, lässt sich aber durch eigene Regeln integrieren. Hierbei kann die KI bei der Erstellung der Regeln gute Dienste tun. Eine gute Hilfestellung bietet hier auch der webbasierte Regelgenerator valegen.

Test-Setup: Astrogon als Grundlage für das Linting-System

Bevor es an die detaillierte Umsetzung des dreistufigen Linting-Konzepts geht, ist eine praktische Arbeitsumgebung einzurichten. Als grundlegendes Code- und Dokumentations-Beispiel dient Astrogon – ein vielseitiges Astro-Theme, das sich ideal für die Demonstration des Linting-Systems eignet. Astrogon ist ein schnell anpassbares, Mehrzweck-Website-Template, das auf Astro JS, Tailwind CSS und React basiert. So bildet es eine solide Grundlage für verschiedene Website-Typen – von Blogs über Dokumentationsseiten bis hin zu Portfolio-Websites.

Astrogon eignet sich deshalb als Demo-Basis, weil es:

1. Verschiedene Dateitypen enthält: .astro, .tsx, .js, .md, .mdx, .css
2. Realistische Komplexität bietet: ein echtes Projekt mit authentischen Herausforderungen
3. Einen modernen Stack verwendet: aktuelle Technologien, die typisch für moderne Webprojekte sind
4. Gut strukturiert ist: klare Ordnerstruktur für effektives Linting
5. Content-fokussiert arbeitet: viel Text-Content für Prosa-Linting

Durch einen Fork des originalen Astrogon Repository, den man lokal klont, lässt sich das Projekt einfach aufsetzen.

# Create a fork (via GitHub.com)

#  Clone repository
git clone 
cd my-linting-project

# Install dependencies
npm install

# Fix existing vulnerabilities
npm audit fix

# Start development server
npm run dev

Nach der Installation steht eine vollständig funktionsfähige Website mit folgender Struktur parat:

my-linting-project/
├── docs/ # Documentation
├── public/ # Static public viewable resources
├── src/
│ ├── assets/ # Pictures, icons,...
│ ├── components/ # reusable components
│ ├── content/ # Markdown/MDX content collections
│ ├── lib/ # Utility functions
│ ├── pages/ # Astro-pages (Routing)
│ ├── styles/ # CSS/SCSS files
│ ├── types/ # TypeScript type-definitions
│ ├── content.config.ts # Content Collections configuration
│ └── env.d.ts # Environment variables types
├── .editorconfig # Editor-configuration
├── .prettierrc # Preconfigured prettier
├── .markdownlint.json # Preconfigured markdownlot
├── astro.config.mjs # Astro configuration
├── package.json # Dependencies and scripts
├── tailwind.config.js # Tailwind CSS configuration
├── tsconfig.json # TypeScript Configuration
└── wrangler.jsonc # Cloudflare workers configuration

Integration der Linter in den Stack

Modernes Linting geht weit über die reine Syntaxprüfung hinaus und umfasst drei komplementäre Dimensionen der Qualitätskontrolle: Code-Qualität für die Logik, Formatierung für die Konsistenz und Prosa-Linting für die menschliche Lesbarkeit. Für diese drei Aspekte kommen verschiedene Linter zum Einsatz: ESLint für die Code-Qualität, Prettier für die Formatierung und Vale für das Prosa-Linting.

Code-Qualität mit ESLint: ESLint bildet das Fundament des Linting-Stacks. Es analysiert TypeScript-, JavaScript- und Astro-Dateien auf potenzielle Fehler, Style-Inkonsistenzen und Best-Practice-Verletzungen. Die Installation leitet der folgende Befehl ein:

npm install -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser astro-eslint-parser eslint-plugin-astro

Im nächsten Schritt folgt das Anlegen der Datei .eslintrc.js, die die Konfiguration für die verschiedenen Dateitypen definiert. Dies gelingt am einfachsten über den offiziellen Konfigurations-Wizard von ESLint:

npm init @eslint/config@latest

module.exports = {
  extends: [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
  ],
  parser: "@typescript-eslint/parser",
  plugins: ["@typescript-eslint"],
  parserOptions: {
    ecmaVersion: "latest",
    sourceType: "module",
  },
  env: {
    node: true,
    browser: true,
    es2022: true,
  },
  rules: {
    "@typescript-eslint/no-unused-vars": ["error", { "argsIgnorePattern": "^_" }],
    "@typescript-eslint/no-explicit-any": "warn",
    "@typescript-eslint/no-empty-interface": "off",
  },
  overrides: [
    {
      files: ["*.astro"],
      extends: ["plugin:astro/recommended"],
      parser: "astro-eslint-parser",
      parserOptions: {
        parser: "@typescript-eslint/parser",
        extraFileExtensions: [".astro"],
      },
    },
  ],
};

Anschließend sind die aufrufenden npm-Skripte in der Datei package.json zu hinterlegen.

{
  "scripts": {
    "lint": "eslint ./src --ext .js,.ts,.jsx,.tsx,.astro --fix",
    "lint:check": "eslint ./src --ext .js,.ts,.jsx,.tsx,.astro"
  }
}

Der Befehl npm run lint korrigiert dann automatisch behebbare Probleme, während npm run lint:check nur überprüft, ohne Änderungen vorzunehmen, und die Ergebnisse im Terminal ausgibt.

Code-Formatierung mit Prettier: Prettier sorgt für einheitliche Code-Formatierung und nimmt Entwicklern die Diskussion über Code-Style ab. Besonders in Astro-Projekten mit gemischten Dateitypen ist eine konsistente Formatierung essenziell. Prettier lässt sich mit folgendem Befehl installieren:

npm install -D prettier prettier-plugin-astro prettier-plugin-tailwindcss

Die Konfiguration von .prettierrc\ im Root-Verzeichnis des Repository berücksichtigt die spezifischen Anforderungen von Astro-Projekten:

{
  "plugins": ["prettier-plugin-astro", "prettier-plugin-tailwindcss"],
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 80,
  "useTabs": false,
  "bracketSpacing": true,
  "bracketSameLine": false,
  "arrowParens": "always",
  "endOfLine": "lf",
  "overrides": [
    {
      "files": ["*.astro"],
      "options": {
        "parser": "astro"
      }
    },
    {
      "files": ["*.md", "*.mdx"],
      "options": {
        "printWidth": 100,
        "proseWrap": "always"
      }
    }
  ]
}

Sind die Abhängigkeiten installiert und die Konfiguration angelegt, werden die entsprechenden npm-Skripte in der Datei package.json eingefügt:

{
  "scripts": {
      ...
      ...
    "format": "prettier --write ./src --log-level silent",
    "format:check": "prettier --check ./src --log-level silent"
  }
}

Der Befehl npm run format korrigiert anschließend automatisch behebbare Probleme, während npm run format:check nur überprüft, ohne Änderungen vorzunehmen, und die Ergebnisse im Terminal ausgibt.

Prosa-Linting mit Vale: Vale ist ein Open-Source-Tool für das Prosa-Linting, das wie ein Code-Linter funktioniert, aber Fließtext verarbeitet. Es prüft Texte auf stilistische Fehler, wiederkehrende Muster und Verstöße gegen vordefinierte oder eigene Stilrichtlinien. Es funktioniert mit Markdown, HTML, AsciiDoc oder reStructuredText und analysiert diese Formate anhand konfigurierter Regeln. Die Style-Guides, anhand derer Vale überprüft, können frei gewählt, angepasst oder erweitert werden – beispielsweise nach Vorbildern von Google, Microsoft oder eigenen Anforderungen.

Typische Regeln erkennen etwa unnötige Passiv-Konstruktionen, zu viele Wiederholungen, fehlende Oxford-Kommas – also das Komma vor der Konjunktion in einer Aufzählung, das helfen soll, Missverständnisse zu vermeiden – oder „Weak Words“ wie „viele“ oder „manchmal“. Die Ergebnisse zeigt Vale direkt im Editor, in der Kommandozeile oder als Teil automatisierter CI-Prozesse.

Vale erfordert eine plattformspezifische Installation sowie den Download der Style-Guides und LibreOffice-kompatibler Hunspell-Wörterbücher (.dic/.aff-Dateien) für die Rechtschreibprüfung in anderen Sprachen als Englisch. Ja, die Kombination von Prosa-Linting-Style-Guides (wie Vale, Google oder Microsoft Style Guides) mit einem deutschen Wörterbuch ist durchaus sinnvoll und funktioniert einwandfrei – Vale nutzt Hunspell-Dictionaries unabhängig voneinander für Rechtschreibung und Stilregeln. Rechtschreibprüfung prüft Wörter auf Korrektheit, während Prosa-Linting Stil, Lesbarkeit und Konventionen überwacht; beide ergänzen sich nahtlos in einem Workflow. Für das beispielhafte Repository habe ich entsprechende Linux/macOS– und Windows-Skripte angelegt, die das Setup erledigen. Getestet ist aktuell nur das Bash-Skript, das PowerShell-Skript wurde via KI automatisiert auf Basis des Bash-Skripts erstellt.

Abweichend von der standardmäßigen Vorgehensweise, bei der Probleme mit dem in Vale integrierten Installer vale sync auftraten, laden die Skripte die git-Repositories für die Styleguides manuell herunter und löschen alle git-spezifischen Inhalte.

# Linux/macOS
chmod +x .vale/install-vale.sh
./.vale/install-vale.sh

# Windows
powershell -ExecutionPolicy Bypass -File .vale/install-vale.ps1

Nach Ausführen der Skripte entsteht folgendes Verzeichnis im Root-Verzeichnis des Repositories:

my-linting-project/
├── .vale/
  ├── dictionaries
  │    ├── de_DE.aff
  │    ├── de_DE.dic
  ├── styles
       ├── Base
       │    ├── accept.txt
	   │    ├── reject.txt
       │    ├── Microsoft/
       │    ├── write-good/ 
  ├── install-vale.ps1
  ├── install-vale.sh
  └── vale

Zu beachten ist dabei noch, alle dynamisch generierten Inhalte in die .gitignore-Datei aufzunehmen.

# Vale binary (install with npm run install-vale)
.vale/dictionaries
.vale/styles/Microsoft
.vale/styles/write-good
.vale/vale
.vale/vale.exe

Vale-Styleguides auswählen und installieren

Das Installationsskript lädt nicht nur Vale herunter, sondern auch die benötigten Styleguides. Auf der Vale-Website sind, neben einigen weiteren spezifischen, vier wesentliche Style-Guides referenziert:

Google

• Starker Fokus auf technische Konsistenz und Präzision für Entwickler.
• Große Ausnahmeliste für Akronyme und Begriffe aus APIs.
• Substitutionslisten mit Google-typischer Terminologie.
• Stil: direkt, technisch, an Entwickler gerichtet, prägnant, präzise.
• Quelle Git, Quelle Style-Guide

Microsoft

• Sehr starke Gewichtung auf Inklusivität und Barrierefreiheit.
• Klare Satzlängen- und Limits für Wörter.
• Hunderte produkt- und communityspezifische Begriffe.
• Stil: freundlich, inklusiv, leserorientiert, markengerecht, barrierefrei.
• Quelle Git, Quelle Style-Guide

Red Hat

• Strikte Regeln zu „Open Source“-neutraler Sprache und Kollaboration.
• Erlaubt keinen Produkt-Bias, eigene Accessibility- und Bias-Listen.
• Regeln für CLI-Beispiele, Dateipfade und produktneutrale Formulierungen.
• Bevorzugt kollaborativen Duktus und Community-Perspektive.
• Stil: offen, kollaborativ, communitygetrieben, produktneutral, inklusiv.
• Quelle Git, Quelle Style-Guide

Write-good

• Fokussiert sich rein auf sprachliche Klarheit und verbessert Lesbarkeit und Stil, ohne produkt- oder technikspezifische Prüfkriterien.
• In modernen Dokumentations-Workflows eignen sich Write-Good-Regeln ergänzend, um die sprachliche Qualität unabhängig von der Plattform zu verbessern.
• Write-Good Vale Style-Guide

Im Folgenden kommt der „Microsoft Style Guide“ zum Einsatz – erweitert um die Style-Guides „write-good“, „MDX“ und „Vale Core“. Diese sind wie folgt charakterisiert:

Microsoft Style Guide: Unternehmensstandards für technische Dokumentation

write-good: allgemeine Regeln für klares Schreiben

Vale Core: grundlegende Prosa-Regeln

MDX: Prüfung der Sprache innerhalb von JSX Tags

Beim Einsatz unterschiedlicher Style-Guides in Kombination lässt sich in manchen Situationen schwer identifizieren, warum welche Regel benötigt wird. Ein Beispiel macht dies klarer. Gegeben ist folgende MDX-Datei:

---
title: "Using Feature Y"
author: "Adesso"
---

# Feature Y Benefits

You will be able to use this feature very effectively. It was developed by adeso and their team.


  DO NOT use this feature if your environment isn't set correctly.


Step 1: Initializing the data source
Step 2 Call the performOperation() function
Step 3: Confirm the output's accuracy

> Note: The process can be slow. It is important that you wait patiently.

For details, check our doc [documentation](htp://example.com/feature-y).

Die Ergebnisse des Lintings fasst die folgende Tabelle zusammen:

Fehler	Welcher Regelsatz	Erklärungen & Korrektur
Autor „Adesso“ und „adeso“ inkonsistent geschrieben	Custom Regel	Korrigiert in „adesso“
Großschreibung in JSX-Komponente ``	MDX-Regelsatz	Meldet falsche Großschreibung oder unbekannte JSX-Tags, erwartet `` o.Ä.
Markdown-Liste ohne korrekte Aufzählungszeichen	MDX-Regelsatz	Fehlt das `-` oder die Nummerierung bei Liste (z.B. `Step 2` ist kein Listenelement)
Unsichere URL im Link (htp statt http)	Microsoft Regelsatz	Erkennt ungültige URLs, fordert Korrektur auf gültiges Schema (`
Übermäßiger Gebrauch von Floskeln (z.B. „very effectively“, „It is important that“)	Write-Good	Empfiehlt prägnantere Ausdrucksweise („effectively“, „Wait patiently.“)
Use of first-person pronouns („You will be able…“, „you wait patiently“) in nicht passender Art	Microsoft Regelsatz	Warnt bei unpassender Verwendung von Personalpronomen, schlägt Sparse-Usage vor
Passiver Sprachgebrauch („was developed“)	Write-Good & Microsoft	Empfiehlt aktive Formulierung, z.B. „adesso developed this feature.“

Die korrigierte MDX-Datei sieht nach der Regelprüfung dann wie folgt aus:

---
title: "Using Feature Y"
author: "adesso"
---

# Feature Y Benefits

You can use this feature effectively, adesso and their team developed it.


  Do not use this feature if your environment is not set correctly.


- Step 1: Initialize the data source
- Step 2: Call the performOperation() function
- Step 3: Confirm the output's accuracy

> Note: The process can be slow. Please wait patiently.

For details, check our [documentation](

Mithin ergeben sich folgende Einschränkungen:

• Die Vale-Style-Guides sind nur für englischen Text optimiert, eine Anpassung an Deutsch oder andere Sprachen scheint bisher nicht vorgesehen zu sein.
• Die Style-Guides basieren auf klassischen Regular Expressions. Wer KI-basierte Ansätze erwartet, wird enttäuscht.
• Speziell in größeren Projekten empfiehlt es sich einen eigenen Style-Guide aufzubauen. Die Konfiguration von Vale erfordert eine kontinuierliche Anpassung an die Bedürfnisse des Projekts.

Konfigurieren und Anpassen von Vale (.vale.ini)

Die Vale-Konfigurationsdatei gibt an, in welchen Verzeichnissen und mit welchen Style-Vorgaben das Tool den Text überprüfen soll. Für das Beispiel sei angenommen, dass sich der englische Content in den Unterverzeichnissen des Ordners /src/content befindet.

# Vale configuration file
# See: 
Packages = MDX

StylesPath = .vale/styles
# Add dictionary path for German dictionaries
DictionaryPath = .vale/dictionaries

MinAlertLevel = error

# File type associations - English content (excluding German docs)
[src/content/**]{.md,.mdx}

# Enable/disable specific styles for English content
BasedOnStyles = Vale, write-good, Microsoft

# Enable rules
Vale.Terms = YES  # Disables term-based checks. Example: Avoid using "jargon".
Vale.Spelling = YES  # Disables spelling checks. Example: "recieve" instead of "receive".
Vale.Vocab = YES  # Disables vocabulary checks. Example: Using "utilize" instead of "use".
Vale.Repetition = YES  # Disables repetition checks. Example: "very very good".
Vale.Wordiness = YES  # Disables wordiness checks. Example: "in order to" instead of "to".

# Write-good rules (English-specific)
write-good.Weasel = YES  # Disables detection of weasel words. Example: "some people say".
write-good.TooWordy = YES  # Disables detection of overly wordy phrases. Example: "due to the fact that".
write-good.So = YES  # Disables detection of sentences starting with "so". Example: "So, we decided to...".
write-good.ThereIs = YES  # Disables detection of "there is/are" constructions. Example: "There is a need for...".
write-good.Passive = YES  # Disables detection of passive voice. Example: "The ball was thrown by John".
write-good.Adverbs = YES  # Disables detection of adverbs. Example: "He ran quickly".
write-good.Cliches = YES  # Disables detection of cliches. Example: "Think outside the box".
write-good.E-Prime = YES  # Disables detection of E-Prime violations. Example: "He is a teacher".
write-good.Illusions = YES  # Disables detection of ambiguous phrases. Example: "The results were significant".

# Microsoft style rules (English-specific)
Microsoft.Gender = YES  # Ensures gender-neutral language is used. Example: Use "they" instead of "he/she".
Microsoft.PassiveVoice = YES  # Flags sentences written in passive voice. Example: "The report was written by Sarah".
Microsoft.Cliches = YES  # Detects overused phrases and cliches. Example: "At the end of the day".
Microsoft.Jargon = YES  # Highlights technical jargon that may confuse readers. Example: "Leverage synergies".
Microsoft.Complexity = YES  # Identifies sentences that are overly complex or difficult to read. Example: "The implementation of the solution was carried out in a manner that ensured...".
Microsoft.Redundancy = YES  # Flags redundant phrases or words. Example: "Free gift".
Microsoft.Spelling = YES  # Checks for spelling errors based on Microsoft's style guide. Example: "color" vs. "colour".
Microsoft.Spacing = YES  # Disables because of D2 diagrams - Allows ignoring spacing-related issues. Example: "word  word".
Microsoft.Contracting = YES  # Allows ignoring contracting-related issues. Example: "isn't" vs. "is not".
Microsoft.Quotes = YES  # Allows ignoring quotes-related issues. Example: "'single quotes' vs. "double quotes".
Microsoft.Contractions = YES  # Allows ignoring contractions-related issues. Example: "can't" vs. "cannot".
Microsoft.Foreign = YES  # Allows ignoring foreign phrases and words. Example: "et cetera".
Microsoft.Plurals = YES  # Allows ignoring pluralization-related issues. Example: "criterias" vs. "criteria".
Microsoft.Auto = YES  # Disables automatic suggestions for corrections. Example: "autocorrect".
Microsoft.AMPM = YES  # Allows ignoring AM/PM formatting issues. Example: "2 PM" vs. "14:00".
Microsoft.DateOrder = YES  # Allows ignoring date order-related issues. Example: "MM/DD/YYYY" vs. "DD/MM/YYYY".
Microsoft.Dashes = YES  # Allows ignoring dash-related issues. Example: "em-dash" vs. "en-dash".
Microsoft.DateFormat = YES  # Allows ignoring date format-related issues. Example: "2025-10-01" vs. "01/10/2025".
Microsoft.Units = YES  # Allows ignoring unit-related issues. Example: "5kg" vs. "5 kg".
Microsoft.Avoid = YES  # Allows ignoring "avoid" suggestions. Example: "Avoid using passive voice".
Microsoft.Negative = YES  # Allows ignoring negative phrasing suggestions. Example: "Not bad" vs. "Good".

Nun sind noch die richtigen Cross-Platform npm-Skripte für Vale bereitzustellen, um den Linter zu installieren und aufzurufen.

{
  "scripts": {
	  ...
	  ...
    "postinstall": "npm run install-vale",
	"install-vale": "node -e \"const cmd = process.platform === 'win32' ? 'powershell -ExecutionPolicy Bypass -File .vale/install-vale.ps1' : 'bash .vale/install-vale.sh'; require('child_process').exec(cmd, (err, stdout, stderr) => { if (err) { console.error(stderr); process.exit(1); } console.log(stdout); })\"",
    "prose": "node -e \"const vale = process.platform === 'win32' ? './.vale/vale.exe' : './.vale/vale'; const { exec } = require('child_process'); exec(vale + ' --config=.vale.ini src/content', (err, stdout, stderr) => { console.log(stdout); if (stderr) console.error(stderr); if (err) process.exit(1); });\""
  }
}

• postinstall: Wird automatisch aufgerufen, wenn npm install ausgeführt wird
• install-vale: Ruft je nach Plattform die richtigen Installationsscripte auf
• prose: Ruft das Linting auf und gibt Fehler in der Kategorie „error“, „warning“ und „information“ aus

Ausnahmen für Sonderfälle sind eigens zu definieren, etwa für Situationen, in denen Vale eine Regel bewusst ignorieren soll. Beispielsweise würde die Regel write-good.So für den Satz „So the experiment failed because the measurements were taken incorrectly“ normalerweise den folgenden Fehler melden:

 src/content/blog/myfile.mdx
 188:52  error  Don't start a sentence with     write-good.So 
                'So '.                                        

✖ 1 error, 0 warnings and 0 suggestions in 38 files.

Um für diesen spezifischen Fall die Prüfung abzuschalten, ist die entsprechende Zeile mit einem Kommentar zu umfassen:

{/*  */}

So the experiment failed because the measurements were taken incorrectly

{/*  */}

Zu beachten ist dabei, dass die beiden Kommentar-Tags und die betroffene Zeile durch einen Zeilenumbruch getrennt sein müssen. Da es sich zudem um MDX-Dateien handelt, müssen die Zeilen erst mit einem JSX-Kommentarblock umschlossen werden, damit der Server nicht meckert, und anschließend mit einem HTML-Kommentarblock, damit Vale diesen erkennt. Darüber hinaus benötigt Vale – mit folgenden beiden Zeilen in der vale.ini – einen Hinweis, dass MDX-Dateien letztlich auch als Markdown-Dateien zu behandeln sind:

[formats]
mdx = md

Im Falle kompletter Textblöcke oder wenn der Grund der Deaktivierung der Vale-Regel benannt werden soll, ist es ebenfalls möglich, nur einzelne Regeln abzuschalten:

{/*  */}

So the experiment failed because the measurements were taken incorrectly

{/*  */}

Seitdem wir Mitte der Neunziger-Jahre an dem ersten Buch der Pattern-Oriented-Software-Architecture-Serie gearbeitet haben, tauchte auf Konferenzen und in Fachgremien immer wieder die Diskussion auf, was Softwarearchitektur denn konkret beinhaltet. Vergleiche mit Gebäudearchitektur, Elektrotechnik-Schaltplänen oder Kunst schienen schon damals zu kurz gegriffen, obwohl die genannten Gewerke durchaus einige Gemeinsamkeiten mit Softwarearchitektur aufwiesen. Der folgende Artikel illustriert meine heutige Sicht.

Prolog: Die Frage, die den Berufsstand verfolgt

Versammelt jemand zehn Softwarearchitekten in einem Raum und bittet sie, ihr Handwerk zu definieren, trägt diese Person wahrscheinlich elf verschiedene Antworten und Kopfschmerzen davon. Das liegt nicht daran, dass Architekten von Natur aus widersprüchlich wären, obwohl einige dies durchaus sind, sondern weil Softwarearchitektur eine eigentümliche Position im Pantheon menschlicher Bestrebungen einnimmt. Sie sitzt unbequem an der Kreuzung mehrerer Disziplinen, verweigert eine ordentliche Kategorisierung, verwendet antike Traditionen und erfindet gleichzeitig völlig neue Paradigmen.

Dazu folgende Überlegung: Als der Architekt Frank Lloyd Wright sein Haus Fallingwater entwarf, arbeitete er mit Materialien, die seit Jahrtausenden existierten. Stein, Wasser, Stahl, Beton. Diese Substanzen besaßen bekannte Eigenschaften, verstandene Verhaltensweisen und Jahrhunderte akkumulierter Weisheit über ihre Verwendung. Als Ada Lovelace den ersten Algorithmus schrieb, arbeitete sie mit nichts als reiner Abstraktion, mathematischer Notation auf Papier, die Operationen für eine Maschine beschrieb, die kaum existierte. Softwarearchitekten erben heute beide Traditionen, operieren jedoch in einem Reich, das weder Wright noch Lovelace wiedererkennen könnten.

Die Frage, was Softwarearchitektur wirklich ist, zählt mehr als bloßes philosophisches Nabelschauen vermuten ließe. Die Disziplin prägt immerhin die Praxis, die Lehre, die Bewertung und letztendlich den Bau der digitalen Infrastruktur, von der die moderne Zivilisation zunehmend abhängt.

Das Plädoyer für Architektur als Kunst

Wenn Martin Fowler ein gut gestaltetes System beschreibt, klingt er manchmal eher wie ein Kunstkritiker, der ein Meisterwerk diskutiert, als wie ein Ingenieur. Er spricht von „Eleganz“, von „Klarheit“, von Lösungen, die sich „richtig“ anfühlen. Dies sind nicht die kalten, klinischen Begriffe reiner Ingenieurkunst. Sie tragen ästhetisches Gewicht, subjektives Urteil, einen Appell an etwas jenseits bloßer Funktionalität.

Und tatsächlich durchzieht Kunstfertigkeit die Softwarearchitektur auf mehreren Ebenen. Die Wahl zwischen Microservices und einem Monolithen ist selten eine rein mathematische Entscheidung. Zwei gleich versierte Architekten treffen für dasselbe Problem möglicherweise entgegengesetzte Entscheidungen und schaffen beide erfolgreiche Systeme. Der Unterschied liegt nicht in objektiver Korrektheit, sondern in Vision, im Geschmack, in einem intuitiven Gespür dafür, was sich für den Kontext angemessen anfühlt.

Großartige Softwarearchitektur besitzt eine Qualität, die ihre technischen Spezifikationen transzendiert. Wer das Design von Unix mit seiner Philosophie kleiner, komponierbarer Werkzeuge untersucht oder die klare Trennung der Belange in einer gut gestalteten hexagonalen Architektur beobachtet, erkennt eine unleugbare Schönheit darin. Der Code entwickelt sich zu einer Ausdrucksform, zu einer Methode, dem Chaos roher rechnerischer Möglichkeiten menschliche Bedeutung und Ordnung aufzuerlegen.

Die Architektin, die ein System für Millionen gleichzeitiger Nutzer entwerfen muss, steht vor einem unendlichen Lösungsraum. Sie könnte ereignisgesteuerte Architektur, Aktor-Modelle, reaktive Streams oder unzählige andere Muster wählen. Die Einschränkungen verengen die Optionen, aber selten auf eine einzige „korrekte“ Antwort. Was leitet ihre endgültige Wahl? Erfahrung, gewiss. Technisches Wissen, absolut. Aber auch Intuition, ästhetische Präferenz und eine kreative Vision davon, wie die Teile zusammenpassen sollten. Dies ist die Arbeit einer Künstlerin, die rohe Materialien zu etwas formt, das zuerst in der Vorstellung existiert, bevor es Realität annimmt.

Der kreative Prozess in der Softwarearchitektur spiegelt künstlerisches Bestreben auf eine weitere entscheidende Weise: die Bedeutung des Negativraums, dessen, was bewusst nicht gebaut wird. Ein Bildhauer enthüllt Form durch das Entfernen von Stein. Ein Architekt offenbart Klarheit durch Widerstand gegen die Versuchung, Komplexität hinzuzufügen. Die Zurückhaltung, ein System einfach zu halten, wenn jeder Stakeholder ein weiteres Feature fordert, der Mut, Code zu löschen, statt hinzuzufügen – all das erfordert künstlerische Sensibilität ebenso wie technische Fertigkeit.

Die wissenschaftliche Grundlage unter der Oberfläche

Softwarearchitektur als reine Kunst zu bezeichnen, hieße jedoch, die rigorose wissenschaftliche Grundlage zu ignorieren, auf der sie ruht. Anders als ein Gemälde, das Physik und Logik im Dienste emotionaler Wahrheit verletzen kann, muss ein Softwaresystem unnachgiebigen mathematischen Gesetzen und physischen Einschränkungen gehorchen.

Wenn eine Architektin die erwartete Last auf einem verteilten System berechnet, wendet sie Warteschlangentheorie an, einen Zweig der Mathematik mit Wurzeln in frühen Telefonnetzwerken des zwanzigsten Jahrhunderts. Wenn sie über die Konsistenzgarantien einer Datenbank nachdenkt, befasst sie sich mit dem CAP-Theorem, einem formalen Beweis, der einschränkt, was in verteilter Datenverarbeitung möglich ist. Wenn sie die Zeitkomplexität eines Algorithmus analysiert, arbeitet sie innerhalb des Rahmens der Berechnungskomplexitätstheorie, einem Feld mit tiefen Verbindungen zu Logik und Mathematik.

Die wissenschaftliche Methode durchdringt die architektonische Praxis auf offensichtliche und subtile Weise. Eine Architektin bildet Hypothesen darüber, wie sich ein System unter Last verhalten sollte, entwirft Experimente in Form von Leistungstests, sammelt empirische Daten und verfeinert ihr Verständnis basierend auf Beobachtungen. Sie könnte Chaos Engineering nutzen, um bewusst Ausfälle zu injizieren und die Produktionsumgebung als Labor zu behandeln, in dem sie Theorien über Resilienz gegen die unnachgiebige Realität der physischen Welt testet.

Informatik liefert das theoretische Werkzeugset, das jede Softwarearchitektin beherrschen muss. Konzepte wie Zustandsautomaten, Graphentheorie, formale Verifikation und Berechnungskomplexität sind keine abstrakten akademischen Übungen. Sie bilden die Linse, durch die eine Architektin versteht, was möglich, was effizient und was beweisbar korrekt ist. Beim Entwurf eines Konsensalgorithmus für ein verteiltes System geht es nicht um kreativen Ausdruck, sondern um präzises logisches Denken, das sicherstellt, dass das System unter allen möglichen Ereignissequenzen seine Invarianten beibehält.

Die wissenschaftliche Natur der Softwarearchitektur offenbart sich am deutlichsten, wenn Dinge schiefgehen. Ein Systemausfall ist keine Frage ästhetischer Meinungsverschiedenheit. Er ist eine empirische Tatsache, die systematische Untersuchung verlangt. Die Architektin muss Hypothesen über Grundursachen bilden, Experimente entwerfen, um diese Hypothesen zu testen, und rigorose Denkweisen anwenden, um die zugrunde liegenden Mechanismen zu verstehen. Dies ist Wissenschaft in ihrer reinsten Form: Beobachtung, Hypothese, Experiment und die allmähliche Verfeinerung des Verständnisses durch Konfrontation mit der Realität.

Die praktische Disziplin: Ingenieurwesen

Wäre Softwarearchitektur nur Kunst und Wissenschaft, könnte sie eine intellektuelle Übung bleiben, schön in der Theorie, aber getrennt von der chaotischen Realität des Baus tatsächlicher Systeme. Hier offenbart sich die Ingenieurperspektive als wesentlich. Ingenieurwesen handelt fundamental von Kompromissen, von der Lieferung funktionierender Lösungen innerhalb realer Einschränkungen von Zeit, Geld und menschlicher Fähigkeit.

Ein Ingenieur unterscheidet sich von einem reinen Wissenschaftler in der Akzeptanz, dass Perfektion weder möglich noch überhaupt wünschenswert ist. Wo ein Wissenschaftler die optimale Lösung suchen könnte, sucht ein Ingenieur die ausreichende Lösung, die sich morgen ausliefern lässt, statt der perfekten Lösung, die vielleicht niemals eintrifft. Dieser Pragmatismus steht im Zentrum architektonischer Praxis. Die Architektin muss ständig konkurrierende Belange ausbalancieren: Performance gegen Wartbarkeit, Konsistenz gegen Verfügbarkeit, Sicherheit gegen Benutzerfreundlichkeit, Innovation gegen Zuverlässigkeit.

Die ingenieurmäßige Realität technischer Schulden benötigt ebenfalls eine Betrachtung. Eine Architektin entwirft möglicherweise ein schönes, theoretisch solides System, aber wenn das Team es nicht verstehen, nicht warten oder nicht innerhalb des Geschäftszeitrahmens liefern kann, verwandelt sich jenes elegante Design in ein Hindernis statt in einen Vorteil. Gutes Engineering bedeutet, anzuerkennen, dass das System von realen Menschen mit unterschiedlichen Fähigkeiten gebaut, über Jahre von Personen gewartet, die bei seiner Entstehung nicht anwesend waren, und weiterentwickelt werden muss, um Anforderungen zu erfüllen, die zur Entwurfszeit nicht vollständig bekannt sein können.

Die Ingenieurdisziplin manifestiert sich auch in der Beziehung des Architekten zu Einschränkungen. Wo ein Künstler gegen Einschränkungen aufbegehren oder eine Wissenschaftlerin versuchen könnte, sie durch bessere Theorie zu eliminieren, arbeitet ein Ingenieur innerhalb von Einschränkungen und nutzt sie sogar. Begrenztes Budget erzwingt Einfachheit. Enge Zeitpläne ermutigen die Wiederverwendung bewährter Muster. Legacy-Systeme verlangen kreative Anpassung statt Greenfield-Idealismus. Diese Einschränkungen schmälern die Arbeit nicht, sondern formen sie, ähnlich wie die Eigenschaften von Stahl und Beton prägen, was ein Bauingenieur errichten kann.

Softwarearchitektur als Ingenieurwesen bedeutet, Praktiken wie Standardisierung, Dokumentation und wiederholbare Prozesse anzunehmen. Es bedeutet, Systeme zu schaffen, die Teams betreiben, die nicht an ihrem Design beteiligt waren. Es bedeutet, über Wartung, Überwachung, Bereitstellung und all die unscheinbaren, aber wesentlichen Belange nachzudenken, die ein schönes Design von einem funktionierenden Produkt trennen. Die Architektin muss Fehlermodi, Wiederherstellungsprozeduren, Backup-Strategien und Upgrade-Pfade berücksichtigen. Dies sind Ingenieursbelange, verwurzelt in der Realität, dass Systeme nicht in makelloser Isolation existieren, sondern in der chaotischen, fehleranfälligen realen Welt.

Die Handwerkstradition: Lehre und implizites Wissen

Vielleicht am faszinierendsten ist die Verbindung der Softwarearchitektur zu deutlich älteren Traditionen von Handwerk und Handwerkskunst. Bevor Wissenschaft oder Ingenieurwesen als formale Disziplinen existierten, bauten Menschen Kathedralen, Schiffe und Städte durch akkumuliertes Handwerkswissen, das der Meister an den Lehrling weitergegeben hat. Diese Übertragung impliziten Wissens, von Fertigkeiten, die gelernt, aber nicht vollständig artikuliert werden, bleibt zentral für die architektonische Praxis.

Wenn ein leitender Architekt das Design eines Juniors überprüft, widersetzt sich viel dem Feedback der Formalisierung. Der Senior könnte sagen, das Design „riecht falsch“ oder „fühlt sich spröde an“ oder „es fehlt an Kohäsion“. Dies sind keine wissenschaftlichen Begriffe mit präzisen Definitionen. Sie bilden die Sprache des Handwerks, beschreiben Intuitionen, die sich durch jahrelange Erfahrung entwickelt haben. Ein Meisterschreiner kann fühlen, wenn eine Verbindung nicht ganz richtig sitzt, bevor irgendeine Messung es beweist. Ein Meisterarchitekt kann spüren, wenn ein Design zu Problemen führen dürfte, lange bevor diese Probleme sich manifestieren.

Dieses Handwerkswissen erweitert sich durch Praxis und Mustererkennung. Eine Architektin, die zehn Systeme gebaut hat, trifft andere Entscheidungen als eine, die ein System zehnmal gebaut hat. Die Erfahrung zu sehen, wie Designs altern, zu beobachten, welche Teile von Systemen zu Wartungsalpträumen mutieren und welche durch Jahre der Evolution stabil bleiben, schafft ein intuitives Verständnis, das sich nicht auf Regeln oder Algorithmen reduzieren lässt.

Die Handwerkstradition betont auch die Bedeutung von Werkzeugen und deren richtiger Verwendung. Genauso wie ein Holzarbeiter verschiedene Sägen, Hobel und Meißel beherrschen muss, muss ein Softwarearchitekt Entwurfsmuster, architektonische Stile und Frameworks meistern. Doch Meisterschaft bedeutet, nicht nur zu wissen, wie diese Werkzeuge zu verwenden sind, sondern wann sie zu verwenden sind und zu entscheiden, wann nicht. Ein junger Architekt könnte das neueste architektonische Muster auf jedes Problem anwenden, während ein Meister weiß, dass manchmal der einfachste Ansatz der beste ist, wenngleich er unmodisch erscheint.

Das Lehrlingsmodell, obwohl weniger formal als in mittelalterlichen Gilden, besteht in der Softwareentwicklung durch Mentoring, Code-Review und Paarprogrammierung fort. Architektur lernt sich nicht primär aus Büchern, obwohl Bücher helfen, sondern durch die Arbeit neben erfahrenen Praktikern, durch Absorption ihrer Urteilskraft, ihrer Zurückhaltung, ihrer Denkweise über Probleme. Dieser implizite Wissenstransfer ist nach modernen Standards ineffizient, aber vielleicht unersetzlich für die Entwicklung der tiefen Intuition, die architektonische Meisterschaft charakterisiert.

Eclipse, die quelloffene und frei verfügbare Entwicklungsumgebung für Java, C/C++, PHP und weitere Programmiersprachen, ist in der Version 2025-12 erschienen. Für Windows, macOS und Linux stehen verschiedene eigenständige, erweiterbare IDE-Pakete zur Verfügung. Die Java-Sprachunterstützung von Visual Studio Code und dessen Forks, wie dem KI-Code-Editor Cursor, basiert zwar auf Eclipse, ist aber nicht Teil des Eclipse-IDE-Releases.

Neben dem Support für Java 25, JUnit 6 und Multi-Release-JAR-Dateien gibt es in der Java-IDE sogenannte Lambda Entry Breakpoints. Damit lassen sich selbst dann gezielt Breakpoints in Lambda-Ausdrücken setzen, wenn mehrere verkettete Lambda-Ausdrücke in einer Zeile stehen. Auch hinsichtlich anderer Programmiersprachen gibt es Verbesserungen, beispielsweise um die jeweils aktuelle Version TypeScript 5.9 und PHP 8.5 nutzen zu können.

Mit Java 21 im Gepäck, reif für Java 25

Die Java-IDE unterstützt zwar Java 25 und die in Java implementierte IDE lässt sich auch mit Java 25 ausführen. Dennoch werden, obwohl Java 25 eine LTS-Version ist, für die die Hersteller Long-Term-Support (LTS) versprechen, die Eclipse-Pakete weiterhin mit der vorherigen LTS-Version Java 21 ausgeliefert. Der Grund: In der von Eclipse verwendeten Java-Distribution Eclipse Temurin ist Java 25 noch nicht für Windows on ARM verfügbar. Wer also Java 25 nutzen will, muss es separat installieren.

In Java 25 gibt es zwei neue Sprachfeatures, „Flexible Constructor Bodies“ und „Module Import Declarations“. Ersteres erlaubt in Konstruktoren Anweisungen vor dem Aufruf von super() oder this(). Bei Verwendung einer älteren Java-Version zeigt Eclipse einen Fehler mit dem Hinweis an, dass dies erst ab Java 25 möglich ist. Beim Schreiben einer Modulimportdeklaration kann per Codevervollständigung ein Modul aus einer Liste der verfügbaren Module ausgewählt werden. Die Funktion Organize Imports entfernt unnötige Modulimportdeklarationen, fügt aber weiterhin nur Importdeklarationen auf Klassenebene hinzu.

Java-IDE: Debugging-Optionen und Erstellen von Multi-Release-JARs

Zum Debuggen von Java-Code kann im Editor in der entsprechenden Zeile per Rechtsklick auf den linken Rand und Auswahl des Menüpunkts „Toggle Lambda Entry Breakpoint“ ein Breakpoint für einen Lambda-Ausdruck gesetzt oder wieder entfernt werden. Befinden sich mehrere Lambda-Ausdrücke in der Zeile, erscheint ein Dialog, in dem der Gewünschte aus einer Liste vorhandener Lambda-Ausdrücke ausgewählt werden kann. Im „Open Type“-Dialog lässt sich nun per Camel Case filtern, beispielsweise „outMem“ anstelle von „out*mem“ für OutOfMemoryError. Für die seit Java 23 verfügbaren Markdown-Javadoc-Kommentare können projektspezifische Vorlagen erstellt werden. Außerdem lässt sich einstellen, ob bei der Code-Generierung Markdown- oder klassische Javadoc-Kommentare verwendet werden sollen. Beim Formatieren werden Markdown-Javadoc-Kommentare nun standardmäßig mitformatiert, was sich deaktivieren lässt.

Neu ist die Option zur Erstellung von Multi-Release-JAR-Dateien. Diese enthalten einige der kompilierten Klassen zusätzlich in einer für eine höhere Java-Version kompilierten Variante, die nur dann verwendet wird, wenn die JAR-Datei mit mindestens dieser Java-Version ausgeführt wird. In der IDE legt man dazu zusätzliche Quellcodeordner an und bestimmt dann im Java Build Path über die neue Release-Option die Java-Version, entweder „project default“ oder eine höhere Java-Version. Bei Maven-Projekten müssen die Einstellungen nicht manuell vorgenommen werden, stattdessen werden sie automatisch mit denen des Maven-Compiler-Plug-ins in der pom.xml-Datei synchronisiert.

TypeScript, JavaScript und PHP

Beim Tooling für Webtechnologien bedient sich Eclipse, genauer gesagt Eclipse Wild Web Developer, bei Visual Studio Code und unterstützt damit TypeScript, einschließlich der aktuellen Version 5.9. Bei den Eclipse PHP Development Tools (PDT) wurden diese nach längerer Pause aktualisiert und bieten nun Support für PHP 8.4 und 8.5.

Upgrade oder Download

Für Windows, Linux und macOS werden jeweils zehn erweiterbare Basispakete der Eclipse-Entwicklungsumgebung für unterschiedliche Einsatzzwecke angeboten. Sämtliche Pakete enthalten alles, was zum Ausführen von Eclipse und zum Entwickeln notwendig ist: Java 21 und Git, sowie in den Java-IDE-Paketen zusätzlich Maven und Gradle.

Die Eclipse-IDE-Pakete können über den Eclipse Installer installiert oder als ZIP-Dateien heruntergeladen werden. Eine bestehende Eclipse IDE lässt sich über Help | Check for Updates aktualisieren. Weitere Informationen und die Neuerungen von den an diesem Release beteiligten Eclipse-Projekten finden sich auf der Eclipse-IDE-Webseite.

(map)