Ein Skript beginnt oft harmlos.<\/p>\n\n\n\n
Es soll eine klar umrissene Aufgabe erledigen. Eine API aufrufen. Dateien verschieben. Daten bereinigen. Benutzer anlegen. E-Mails verarbeiten. Einen wiederkehrenden manuellen Ablauf automatisieren.<\/p>\n\n\n\n
Die erste Version ist entsprechend einfach:<\/p>\n\n\n\n
verbinden\ndaten laden\ndaten ver\u00e4ndern\nfertig\n<\/code><\/pre>\n\n\n\nDas ist v\u00f6llig legitim. F\u00fcr kleine, lineare Aufgaben ist ein einzelnes Skript oft die beste L\u00f6sung. Wenig Struktur, wenig Overhead, kurze Entwicklungszeit.<\/p>\n\n\n\n
Problematisch wird es nicht dadurch, dass das Skript l\u00e4nger wird. Problematisch wird es dann, wenn es beginnt, unterschiedliche Verantwortlichkeiten gleichzeitig zu tragen<\/strong>.<\/p>\n\n\n\nDann ist es funktional noch ein Skript, strukturell aber bereits eine Anwendung.<\/p>\n\n\n\n
Der gef\u00e4hrliche \u00dcbergang<\/h2>\n\n\n\n
Dieser \u00dcbergang passiert selten bewusst.<\/p>\n\n\n\n
Kaum jemand entscheidet:<\/p>\n\n\n\n
\nAb heute ist dieses Skript eine Anwendung.<\/p>\n<\/blockquote>\n\n\n\n
Stattdessen kommen Anforderungen einzeln dazu.<\/p>\n\n\n\n
Zuerst soll das Skript nur eine Aktion ausf\u00fchren.<\/p>\n\n\n\n
Dann soll es Unterordner ber\u00fccksichtigen.<\/p>\n\n\n\n
Dann Paging.<\/p>\n\n\n\n
Dann Retry.<\/p>\n\n\n\n
Dann Fortschritt anzeigen.<\/p>\n\n\n\n
Dann einen Dry Run unterst\u00fctzen.<\/p>\n\n\n\n
Dann Fehler nach einem Neustart fortsetzen k\u00f6nnen.<\/p>\n\n\n\n
Dann sollen mehrere Konten unterst\u00fctzt werden.<\/p>\n\n\n\n
Dann braucht man Logs.<\/p>\n\n\n\n
Dann JSON-Ausgabe f\u00fcr Automatisierung.<\/p>\n\n\n\n
Dann Tests.<\/p>\n\n\n\n
Dann eine sch\u00f6nere Benutzeroberfl\u00e4che.<\/p>\n\n\n\n
Jede einzelne Anforderung wirkt klein genug, um sie einfach noch in die bestehende Datei einzubauen.<\/p>\n\n\n\n
Genau hier entsteht das Problem.<\/p>\n\n\n\n
Die Architektur w\u00e4chst nicht mit den Anforderungen mit. Stattdessen w\u00e4chst nur die Datei.<\/p>\n\n\n\n
Ein typischer Verlauf<\/h2>\n\n\n\n
Eine erste Version sieht vielleicht so aus:<\/p>\n\n\n\n
Connect-Service\n\n$items = Get-Items\n\nforeach ($item in $items) {\n Update-Item $item\n}\n<\/code><\/pre>\n\n\n\nDas ist \u00fcberschaubar.<\/p>\n\n\n\n
Dann kommt Pagination:<\/p>\n\n\n\n
while ($nextLink) {\n ...\n}\n<\/code><\/pre>\n\n\n\nDann Retry:<\/p>\n\n\n\n
try {\n ...\n}\ncatch {\n Start-Sleep\n ...\n}\n<\/code><\/pre>\n\n\n\nDann Fortschritt:<\/p>\n\n\n\n
Write-Progress\n<\/code><\/pre>\n\n\n\nDann Zust\u00e4nde:<\/p>\n\n\n\n
$processed++\n$failed++\n$currentFolder = ...\n<\/code><\/pre>\n\n\n\nDann Wiederaufnahme:<\/p>\n\n\n\n
$checkpoint = Import-Clixml ...\n<\/code><\/pre>\n\n\n\nDann Benutzeroberfl\u00e4che:<\/p>\n\n\n\n
Write-Host ...\nClear-Host\n<\/code><\/pre>\n\n\n\nDann verschiedene Betriebsmodi:<\/p>\n\n\n\n
param(\n [switch]$Audit,\n [switch]$Force,\n [switch]$Quiet,\n [switch]$Resume\n)\n<\/code><\/pre>\n\n\n\nIrgendwann enth\u00e4lt dieselbe Datei:<\/p>\n\n\n\n
\n- Authentifizierung<\/li>\n\n\n\n
- API-Zugriffe<\/li>\n\n\n\n
- Paging<\/li>\n\n\n\n
- Retry<\/li>\n\n\n\n
- Batch-Verarbeitung<\/li>\n\n\n\n
- Zustandsverwaltung<\/li>\n\n\n\n
- UI<\/li>\n\n\n\n
- Logging<\/li>\n\n\n\n
- Fehlerbehandlung<\/li>\n\n\n\n
- Persistenz<\/li>\n\n\n\n
- Konfiguration<\/li>\n\n\n\n
- Argumentverarbeitung<\/li>\n\n\n\n
- Testbarkeit<\/li>\n\n\n\n
- Ausgabeformatierung<\/li>\n<\/ul>\n\n\n\n
Dann ist die relevante Frage nicht mehr:<\/p>\n\n\n\n
\nWie f\u00fcge ich noch eine Funktion hinzu?<\/p>\n<\/blockquote>\n\n\n\n
Sondern:<\/p>\n\n\n\n
\nWarum ist das alles \u00fcberhaupt noch in derselben Datei?<\/p>\n<\/blockquote>\n\n\n\n
L\u00e4nge ist nicht das eigentliche Problem<\/h2>\n\n\n\n
Eine Datei mit 1’000 Zeilen ist nicht automatisch schlecht.<\/p>\n\n\n\n
Eine Datei mit 150 Zeilen kann bereits strukturell problematisch sein.<\/p>\n\n\n\n
Entscheidend ist nicht die Anzahl der Zeilen, sondern die Anzahl der Gr\u00fcnde, warum sich der Code \u00e4ndern muss<\/strong>.<\/p>\n\n\n\nWenn eine Datei ge\u00e4ndert werden muss, weil:<\/p>\n\n\n\n
\n- die API ge\u00e4ndert wurde,<\/li>\n\n\n\n
- das UI anders aussehen soll,<\/li>\n\n\n\n
- ein neuer Betriebsmodus dazukommt,<\/li>\n\n\n\n
- Checkpoints anders gespeichert werden,<\/li>\n\n\n\n
- Retry-Verhalten angepasst wird,<\/li>\n\n\n\n
- eine neue Ausgabeform hinzukommt,<\/li>\n<\/ul>\n\n\n\n
dann tr\u00e4gt sie zu viele Verantwortlichkeiten.<\/p>\n\n\n\n
Das ist genau die Art von Kopplung, die sp\u00e4tere \u00c4nderungen teuer macht.<\/p>\n\n\n\n
Das klassische Symptom: Lokale Fixes erzeugen neue Fehler<\/h2>\n\n\n\n
Ein wichtiger Warnhinweis ist, wenn neue Fehler zunehmend durch fr\u00fchere L\u00f6sungen entstehen.<\/p>\n\n\n\n
Beispiel:<\/p>\n\n\n\n
Ein Skript flackert beim Rendern.<\/p>\n\n\n\n
Also wird Clear-Host<\/code> entfernt.<\/p>\n\n\n\nDanach bleiben alte Bildschirmreste stehen.<\/p>\n\n\n\n
Also wird ein In-Place-Renderer gebaut.<\/p>\n\n\n\n
Danach stimmen Zeilenl\u00e4ngen nicht mehr.<\/p>\n\n\n\n
Also wird Padding erg\u00e4nzt.<\/p>\n\n\n\n
Danach funktionieren Unicode-Zeichen nicht zuverl\u00e4ssig.<\/p>\n\n\n\n
Also wird Encoding angepasst.<\/p>\n\n\n\n
Danach entstehen Probleme bei bestimmten PowerShell-Typen.<\/p>\n\n\n\n
Jeder einzelne Fix kann sinnvoll sein.<\/p>\n\n\n\n
Trotzdem verschlechtert sich das Gesamtsystem.<\/p>\n\n\n\n
Das Problem liegt dann nicht in einem bestimmten Bug.<\/p>\n\n\n\n
Das Problem liegt in der Struktur.<\/p>\n\n\n\n
Die entscheidende Erkenntnis<\/h2>\n\n\n\n
Ein Skript h\u00f6rt nicht dann auf, ein Skript zu sein, wenn es \u201egro\u00df\u201c wird.<\/p>\n\n\n\n
Es h\u00f6rt dann auf, ein Skript zu sein, wenn es einen eigenen Lebenszyklus<\/strong> entwickelt.<\/p>\n\n\n\nDazu geh\u00f6ren typischerweise:<\/p>\n\n\n\n
\n- Initialisierung<\/li>\n\n\n\n
- Konfiguration<\/li>\n\n\n\n
- Zust\u00e4nde<\/li>\n\n\n\n
- Fehlerf\u00e4lle<\/li>\n\n\n\n
- Wiederaufnahme<\/li>\n\n\n\n
- Benutzerinteraktion<\/li>\n\n\n\n
- verschiedene Betriebsmodi<\/li>\n\n\n\n
- externe Schnittstellen<\/li>\n\n\n\n
- Tests<\/li>\n\n\n\n
- Persistenz<\/li>\n\n\n\n
- Versionierung<\/li>\n<\/ul>\n\n\n\n
Ein lineares Skript hat einen Ablauf.<\/p>\n\n\n\n
Eine Anwendung hat Zust\u00e4nde.<\/p>\n\n\n\n
Das ist ein fundamentaler Unterschied.<\/p>\n\n\n\n
Linearer Ablauf versus Zustandsmaschine<\/h2>\n\n\n\n
Ein einfaches Skript denkt so:<\/p>\n\n\n\n
start\n \u2193\naktion 1\n \u2193\naktion 2\n \u2193\naktion 3\n \u2193\nende\n<\/code><\/pre>\n\n\n\nEine Anwendung denkt eher so:<\/p>\n\n\n\n
INITIALIZING\n \u2193\nCONNECTING\n \u2193\nREADY\n \u2193\nPROCESSING\n \u2193\nVERIFYING\n \u2193\nCOMPLETED\n<\/code><\/pre>\n\n\n\nZus\u00e4tzlich:<\/p>\n\n\n\n
ERROR\nCANCELLED\nRETRYING\nRESUMING\n<\/code><\/pre>\n\n\n\nSobald solche Zust\u00e4nde relevant werden, sollte der Code sie explizit modellieren.<\/p>\n\n\n\n
Andernfalls entstehen sie trotzdem.<\/p>\n\n\n\n
Dann sind sie nur versteckt in:<\/p>\n\n\n\n
$connected = $true\n$processing = $false\n$failed = 3\n$currentFolder = ...\n$retryCount = ...\n<\/code><\/pre>\n\n\n\nDas ist implizite Zustandslogik.<\/p>\n\n\n\n
Und implizite Zustandslogik ist schwer zu testen und schwer zu verstehen.<\/p>\n\n\n\n
Der Moment f\u00fcr das Refactoring<\/h2>\n\n\n\n
Der richtige Zeitpunkt f\u00fcr ein Refactoring liegt deutlich fr\u00fcher, als viele Entwickler denken.<\/p>\n\n\n\n
Nicht erst dann, wenn die Datei unwartbar ist.<\/p>\n\n\n\n
Sondern wenn erkennbar wird, dass zus\u00e4tzliche Anforderungen neue Arten von Verantwortung<\/strong> einf\u00fchren.<\/p>\n\n\n\nEin pragmatisches Signal ist:<\/p>\n\n\n\n
Wenn eine neue Funktion eine neue dieser Kategorien einf\u00fchrt, sollte die Struktur \u00fcberpr\u00fcft werden:<\/p>\n\n\n\n
UI\nPersistenz\nNetzwerk\nRetry\nState\nParallelit\u00e4t\nResume\nKonfiguration\nTests\nMachine Output\n<\/code><\/pre>\n\n\n\nWenn bereits mehrere davon existieren, ist die Schwelle meist \u00fcberschritten.<\/p>\n\n\n\n
Aus einem Skript wird ein kleines System<\/h2>\n\n\n\n
Der nat\u00fcrliche n\u00e4chste Schritt ist nicht automatisch ein gro\u00dfes Framework.<\/p>\n\n\n\n
Oft gen\u00fcgt eine kleine, klare Modulstruktur.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
File-For-Bankruptcy.ps1\n\nFileForBankruptcy.psm1\n\nPublic\/\n Invoke-FileForBankruptcy.ps1\n\nPrivate\/\n Graph.ps1\n State.ps1\n Checkpoint.ps1\n UI.Terminal.ps1\n UI.Screens.ps1\n\nTests\/\n Graph.Tests.ps1\n Checkpoint.Tests.ps1\n Module.Tests.ps1\n<\/code><\/pre>\n\n\n\nDas sieht zun\u00e4chst nach mehr Dateien aus.<\/p>\n\n\n\n
Aber mehr Dateien bedeuten nicht automatisch mehr Komplexit\u00e4t.<\/p>\n\n\n\n
Im Gegenteil.<\/p>\n\n\n\n
Die Komplexit\u00e4t existiert bereits.<\/p>\n\n\n\n
Die Dateien machen sie nur sichtbar.<\/p>\n\n\n\n
Der Launcher<\/h2>\n\n\n\n
Der Einstiegspunkt sollte m\u00f6glichst langweilig sein.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
Import-Module .\/FileForBankruptcy.psd1\n\nInvoke-FileForBankruptcy @args\n<\/code><\/pre>\n\n\n\nDer Launcher ist nicht der Ort f\u00fcr Gesch\u00e4ftslogik.<\/p>\n\n\n\n
Er startet nur die Anwendung.<\/p>\n\n\n\n
Das klingt banal, hat aber einen gro\u00dfen Vorteil: Der eigentliche Code kann als Modul geladen, getestet und wiederverwendet werden.<\/p>\n\n\n\n
Public und Private<\/h2>\n\n\n\n
Eine sinnvolle Trennung ist:<\/p>\n\n\n\n
Public\/\nPrivate\/\n<\/code><\/pre>\n\n\n\nUnter Public<\/code> liegen Funktionen, die Teil der offiziellen Oberfl\u00e4che sind.<\/p>\n\n\n\nZum Beispiel:<\/p>\n\n\n\n
Invoke-FileForBankruptcy\n<\/code><\/pre>\n\n\n\nUnter Private<\/code> liegt die Implementierung.<\/p>\n\n\n\nZum Beispiel:<\/p>\n\n\n\n
Get-FBMailFolders\nInvoke-FBGraphBatch\nSave-FBCheckpoint\nShow-FBProcessingScreen\n<\/code><\/pre>\n\n\n\nDas verbessert nicht nur die \u00dcbersicht.<\/p>\n\n\n\n
Es zwingt dazu, \u00fcber die \u00f6ffentliche API des eigenen Tools nachzudenken.<\/p>\n\n\n\n
API-Zugriffe geh\u00f6ren in eine eigene Schicht<\/h2>\n\n\n\n
Netzwerkcode sollte m\u00f6glichst nicht direkt mit UI-Code vermischt werden.<\/p>\n\n\n\n
Schlecht:<\/p>\n\n\n\n
Write-Host \"Processing folder...\"\n\n$response = Invoke-MgGraphRequest ...\n\nWrite-Host \"Done\"\n<\/code><\/pre>\n\n\n\nBesser:<\/p>\n\n\n\n
$result = Invoke-FBFolderProcessing\nShow-FBFolderResult $result\n<\/code><\/pre>\n\n\n\nDie API-Funktion wei\u00df dann nichts \u00fcber Farben, Spinner oder Terminalbreite.<\/p>\n\n\n\n
Sie liefert Daten.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
[pscustomobject]@{\n Folder = $folderName\n Success = 120\n Failed = 2\n Retried = 4\n}\n<\/code><\/pre>\n\n\n\nDie UI entscheidet, wie diese Daten dargestellt werden.<\/p>\n\n\n\n
Das ist mehr als \u201eClean Code\u201c<\/h2>\n\n\n\n
Diese Trennung hat einen sehr praktischen Nutzen.<\/p>\n\n\n\n
Wenn dieselbe Engine sowohl eine TUI als auch JSON-Ausgabe erzeugen kann, ist die Architektur wahrscheinlich gesund.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
.\\tool.ps1\n<\/code><\/pre>\n\n\n\nliefert eine interaktive Oberfl\u00e4che.<\/p>\n\n\n\n
Und:<\/p>\n\n\n\n
.\\tool.ps1 -Quiet\n<\/code><\/pre>\n\n\n\nliefert:<\/p>\n\n\n\n
{\n \"processed\": 120,\n \"failed\": 0,\n \"remaining\": 0\n}\n<\/code><\/pre>\n\n\n\nDie Gesch\u00e4ftslogik ist dieselbe.<\/p>\n\n\n\n
Nur der Renderer ist ein anderer.<\/p>\n\n\n\n
Das ist ein gutes Architektur-Signal.<\/p>\n\n\n\n
Quiet Mode als Architekturtest<\/h2>\n\n\n\n
Ein -Quiet<\/code>-Modus wirkt zun\u00e4chst wie ein kleines Feature.<\/p>\n\n\n\nTats\u00e4chlich ist er ein hervorragender Test.<\/p>\n\n\n\n
Wenn -Quiet<\/code> schwer einzubauen ist, weil \u00fcberall im Code direkt Write-Host<\/code> verwendet wird, ist die UI zu stark mit der Logik gekoppelt.<\/p>\n\n\n\nWenn die Kernlogik stattdessen nur Objekte zur\u00fcckgibt, ist es einfach:<\/p>\n\n\n\n
$result = Invoke-Processing\n\nif ($Quiet) {\n $result | ConvertTo-Json\n}\nelse {\n Show-Result $result\n}\n<\/code><\/pre>\n\n\n\nDie Ausgabeform wird damit austauschbar.<\/p>\n\n\n\n
-WhatIf<\/code> ist mehr als Komfort<\/h2>\n\n\n\nEin weiteres Reifezeichen ist echtes PowerShell-Verhalten.<\/p>\n\n\n\n
Mit:<\/p>\n\n\n\n
[CmdletBinding(SupportsShouldProcess = $true)]\n<\/code><\/pre>\n\n\n\nkann das Tool native Mechanismen unterst\u00fctzen:<\/p>\n\n\n\n
.\\tool.ps1 -WhatIf\n<\/code><\/pre>\n\n\n\nDas ist deutlich besser als ein selbst erfundener -DryRun<\/code>, wenn das Tool ohnehin in PowerShell lebt.<\/p>\n\n\n\nDer Vorteil ist nicht nur Konvention.<\/p>\n\n\n\n
ShouldProcess<\/code> zwingt dazu, klar zu definieren:<\/p>\n\n\n\n\nWas genau ist die mutierende Operation?<\/p>\n<\/blockquote>\n\n\n\n
Das ist eine Architekturfrage.<\/p>\n\n\n\n
Audit und Mutation sollten getrennt sein<\/h2>\n\n\n\n
Ein gutes Tool trennt:<\/p>\n\n\n\n
Was w\u00fcrde passieren?\n<\/code><\/pre>\n\n\n\nvon:<\/p>\n\n\n\n
F\u00fchre es aus.\n<\/code><\/pre>\n\n\n\nDas ergibt zwei klar unterschiedliche Phasen:<\/p>\n\n\n\n
AUDIT\n\u2192 Zustand lesen\n\u2192 Umfang bestimmen\n\u2192 Risiken anzeigen\n\nEXECUTION\n\u2192 \u00c4nderungen durchf\u00fchren\n<\/code><\/pre>\n\n\n\nDas verbessert Sicherheit und Verst\u00e4ndlichkeit.<\/p>\n\n\n\n
Nebenbei kann der Audit oft mit geringeren Berechtigungen laufen.<\/p>\n\n\n\n
Beispiel:<\/p>\n\n\n\n
Audit:\nMail.Read\n\nMutation:\nMail.ReadWrite\n<\/code><\/pre>\n\n\n\nDas ist Least Privilege praktisch umgesetzt.<\/p>\n\n\n\n
Retry ist keine Fehlerbehandlung<\/h2>\n\n\n\n
Ein h\u00e4ufiger Fehler ist:<\/p>\n\n\n\n
catch {\n Start-Sleep 2\n retry\n}\n<\/code><\/pre>\n\n\n\nDas wirkt robust, ist aber oft nur verschobenes Scheitern.<\/p>\n\n\n\n
Ausgereifte Retry-Logik unterscheidet mindestens:<\/p>\n\n\n\n
429\n5xx\n4xx\nTimeout\nPartial Batch Failure\n<\/code><\/pre>\n\n\n\nEin 429 Too Many Requests<\/code> ist etwas anderes als ein 403 Forbidden<\/code>.<\/p>\n\n\n\nEin 500<\/code> ist etwas anderes als ein ung\u00fcltiger Request.<\/p>\n\n\n\nDie Reaktion muss entsprechend unterschiedlich sein.<\/p>\n\n\n\n
Partial Failure ver\u00e4ndert die Architektur<\/h2>\n\n\n\n
Bei Batch-Operationen gibt es nicht nur:<\/p>\n\n\n\n
erfolgreich\nfehlgeschlagen\n<\/code><\/pre>\n\n\n\nEin Batch kann so aussehen:<\/p>\n\n\n\n
20 Requests\n\n18 erfolgreich\n1 throttled\n1 dauerhaft fehlgeschlagen\n<\/code><\/pre>\n\n\n\nDann muss der Zustand pro Element modelliert werden.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
SucceededIds\nRetryIds\nFailedIds\n<\/code><\/pre>\n\n\n\nEin simples:<\/p>\n\n\n\n
Success = 18\nFailed = 2\n<\/code><\/pre>\n\n\n\nreicht sp\u00e4testens dann nicht mehr, wenn Resume oder Checkpoints unterst\u00fctzt werden.<\/p>\n\n\n\n
Resume macht aus einem Skript endg\u00fcltig eine Anwendung<\/h2>\n\n\n\n
Wiederaufnahme ist eine klare Grenze.<\/p>\n\n\n\n
Sobald ein Tool nach einem Abbruch sp\u00e4ter weiterarbeiten k\u00f6nnen soll, braucht es persistenten Zustand.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
{\n \"processedMessageIds\": [\n \"abc\",\n \"def\"\n ],\n \"startedAt\": \"2026-09-05T14:00:00Z\"\n}\n<\/code><\/pre>\n\n\n\nAb diesem Punkt existiert Zustand au\u00dferhalb des Prozesses.<\/p>\n\n\n\n
Das bedeutet:<\/p>\n\n\n\n
\n- Versionierung<\/li>\n\n\n\n
- Konsistenz<\/li>\n\n\n\n
- Fehlerf\u00e4lle beim Laden<\/li>\n\n\n\n
- veraltete Checkpoints<\/li>\n\n\n\n
- teilweise abgeschlossene Arbeit<\/li>\n<\/ul>\n\n\n\n
Das ist Anwendungslogik.<\/p>\n\n\n\n
Kein einfacher linearer Skriptablauf mehr.<\/p>\n\n\n\n
Checkpoints m\u00fcssen semantisch korrekt sein<\/h2>\n\n\n\n
Ein besonders gef\u00e4hrlicher Fehler ist:<\/p>\n\n\n\n
versucht\n<\/code><\/pre>\n\n\n\nmit:<\/p>\n\n\n\n
erfolgreich\n<\/code><\/pre>\n\n\n\nzu verwechseln.<\/p>\n\n\n\n
Ein Checkpoint darf nicht einfach alle verarbeiteten IDs speichern.<\/p>\n\n\n\n
Er muss wissen, welche Operation tats\u00e4chlich erfolgreich war.<\/p>\n\n\n\n
Sonst entsteht dieses Problem:<\/p>\n\n\n\n
Message A\nPATCH erfolgreich\n\u2192 gespeichert\n\nMessage B\nPATCH fehlgeschlagen\n\u2192 ebenfalls gespeichert\n<\/code><\/pre>\n\n\n\nBeim Resume wird Message B dann \u00fcbersprungen, obwohl sie nie erfolgreich ver\u00e4ndert wurde.<\/p>\n\n\n\n
Das ist ein gutes Beispiel daf\u00fcr, warum Datenmodelle wichtiger werden, sobald Resume existiert.<\/p>\n\n\n\n
Verifikation geh\u00f6rt zum Erfolg<\/h2>\n\n\n\n
Ein Tool sollte nicht nur sagen:<\/p>\n\n\n\n
56 requests completed\n<\/code><\/pre>\n\n\n\nund daraus ableiten:<\/p>\n\n\n\n
SUCCESS\n<\/code><\/pre>\n\n\n\nDie relevante Frage ist:<\/p>\n\n\n\n
\nIst der gew\u00fcnschte Zustand tats\u00e4chlich erreicht?<\/p>\n<\/blockquote>\n\n\n\n
Das sind zwei unterschiedliche Dinge.<\/p>\n\n\n\n
Operation Success\n<\/code><\/pre>\n\n\n\nund:<\/p>\n\n\n\n
State Success\n<\/code><\/pre>\n\n\n\nBeispiel:<\/p>\n\n\n\n
56 PATCH Requests erfolgreich\n<\/code><\/pre>\n\n\n\nist eine Aussage \u00fcber Operationen.<\/p>\n\n\n\n
0 unread messages remaining\n<\/code><\/pre>\n\n\n\nist eine Aussage \u00fcber den Zustand.<\/p>\n\n\n\n
Die zweite ist oft wichtiger.<\/p>\n\n\n\n
Deshalb ist ein Post-Run-Audit sinnvoll:<\/p>\n\n\n\n
Mutation\n \u2193\nVerification\n \u2193\nFinal Result\n<\/code><\/pre>\n\n\n\nTests werden pl\u00f6tzlich sinnvoller<\/h2>\n\n\n\n
Bei einem kleinen Wegwerfskript ist ein Testframework oft unn\u00f6tig.<\/p>\n\n\n\n
Aber sobald Funktionen wie diese existieren:<\/p>\n\n\n\n
Paging\nRetry\nResume\nBatching\nCheckpoint\nVerification\n<\/code><\/pre>\n\n\n\nwerden Tests extrem wertvoll.<\/p>\n\n\n\n
Nicht nur Happy-Path-Tests.<\/p>\n\n\n\n
Gerade Fehlerf\u00e4lle sollten modelliert werden.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
Paging ohne nextLink\nPaging mit mehreren Seiten\n\n429 \u2192 Retry\n500 \u2192 Retry\n403 \u2192 kein Retry\n\nBatch mit 20 Erfolgen\nBatch mit 19 Erfolgen und 1 Fehler\nBatch mit fehlender Response\n\nCheckpoint speichert nur erfolgreiche IDs\n\nResume verarbeitet fehlgeschlagene IDs erneut\n<\/code><\/pre>\n\n\n\nDas sind die Stellen, an denen reale Produktionsfehler entstehen.<\/p>\n\n\n\n
Der wichtigste Architekturtest<\/h2>\n\n\n\n
Ein sehr einfacher Test lautet:<\/p>\n\n\n\n
\nKann ich die Kernlogik ohne Terminal starten?<\/p>\n<\/blockquote>\n\n\n\n
Wenn nein, ist die TUI wahrscheinlich zu stark gekoppelt.<\/p>\n\n\n\n
Ein zweiter:<\/p>\n\n\n\n
\nKann ich die API-Schicht testen, ohne echte API-Calls auszuf\u00fchren?<\/p>\n<\/blockquote>\n\n\n\n
Wenn nein, sind Abh\u00e4ngigkeiten wahrscheinlich zu hart verdrahtet.<\/p>\n\n\n\n
Ein dritter:<\/p>\n\n\n\n
\nKann ich die Verarbeitung mit einem gespeicherten Zustand wieder aufnehmen?<\/p>\n<\/blockquote>\n\n\n\n
Wenn nein, ist State wahrscheinlich nicht explizit genug modelliert.<\/p>\n\n\n\n
Nicht \u00fcber-engineeren<\/h2>\n\n\n\n
Die Gegenreaktion w\u00e4re falsch:<\/p>\n\n\n\n
Jedes Skript sofort in 30 Dateien zerlegen.<\/p>\n\n\n\n
Auch das erzeugt Komplexit\u00e4t.<\/p>\n\n\n\n
Ein einfaches Skript sollte einfach bleiben.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
Get-ChildItem *.log |\n Where-Object LastWriteTime -lt (Get-Date).AddDays(-30) |\n Remove-Item\n<\/code><\/pre>\n\n\n\nDas braucht keine Module, Domain Objects und Repository Interfaces.<\/p>\n\n\n\n
Die Struktur sollte mit der tats\u00e4chlichen Problemkomplexit\u00e4t wachsen.<\/p>\n\n\n\n
Nicht mit theoretischen M\u00f6glichkeiten.<\/p>\n\n\n\n
Eine praktische Heuristik<\/h2>\n\n\n\n
Ein einzelnes Skript ist meist noch passend, wenn:<\/p>\n\n\n\n
\n- der Ablauf linear ist<\/li>\n\n\n\n
- kein persistenter Zustand existiert<\/li>\n\n\n\n
- Fehler einfach behandelt werden k\u00f6nnen<\/li>\n\n\n\n
- nur ein Betriebsmodus existiert<\/li>\n\n\n\n
- keine aufwendige UI notwendig ist<\/li>\n\n\n\n
- wenig externe Integration existiert<\/li>\n<\/ul>\n\n\n\n
Ein Umbau wird interessant, wenn mehrere dieser Punkte auftauchen:<\/p>\n\n\n\n
\n- mehrere Betriebsmodi<\/li>\n\n\n\n
- API-Paging<\/li>\n\n\n\n
- Retry<\/li>\n\n\n\n
- Batch-Verarbeitung<\/li>\n\n\n\n
- komplexe Fehlerbehandlung<\/li>\n\n\n\n
- UI oder TUI<\/li>\n\n\n\n
- Resume<\/li>\n\n\n\n
- Checkpoints<\/li>\n\n\n\n
- Machine-readable Output<\/li>\n\n\n\n
- Tests<\/li>\n\n\n\n
- mehrere Konten oder Targets<\/li>\n\n\n\n
- unterschiedliche Berechtigungen<\/li>\n\n\n\n
- Post-Verification<\/li>\n<\/ul>\n\n\n\n
Nicht einer dieser Punkte allein macht eine Anwendung.<\/p>\n\n\n\n
Die Kombination tut es.<\/p>\n\n\n\n
Die eigentliche Lektion<\/h2>\n\n\n\n
Viele Entwickler betrachten Refactoring als Arbeit, die nach der eigentlichen Funktionalit\u00e4t kommt.<\/p>\n\n\n\n
Das ist zu kurz gedacht.<\/p>\n\n\n\n
Refactoring wird notwendig, wenn die bestehende Struktur beginnt, neue Anforderungen falsch abzubilden.<\/p>\n\n\n\n
Der entscheidende Zeitpunkt ist also nicht:<\/p>\n\n\n\n
\nDer Code sieht unsauber aus.<\/p>\n<\/blockquote>\n\n\n\n
Sondern:<\/p>\n\n\n\n
\nNeue Features erzeugen \u00fcberproportional viele Wechselwirkungen mit bestehenden Features.<\/p>\n<\/blockquote>\n\n\n\n
Dann ist die aktuelle Abstraktion ersch\u00f6pft.<\/p>\n\n\n\n
Der zw\u00f6lfte Patch ist ein Signal<\/h2>\n\n\n\n
Wenn ein Tool bereits diese Geschichte hat:<\/p>\n\n\n\n
Bug\n\u2192 Patch\n\u2192 neuer Bug\n\u2192 Patch\n\u2192 Seiteneffekt\n\u2192 Patch\n\u2192 neuer Sonderfall\n\u2192 Patch\n<\/code><\/pre>\n\n\n\ndann ist der n\u00e4chste Fehler oft nicht mehr das eigentliche Problem.<\/p>\n\n\n\n
Das System versucht mitzuteilen:<\/p>\n\n\n\n
\nDie Struktur passt nicht mehr zur Komplexit\u00e4t.<\/p>\n<\/blockquote>\n\n\n\n
Dann ist ein weiterer Patch m\u00f6glicherweise technisch korrekt und trotzdem die falsche Entscheidung.<\/p>\n\n\n\n
Die bessere Frage lautet:<\/p>\n\n\n\n
\nWelche Verantwortung fehlt als eigene Abstraktion?<\/p>\n<\/blockquote>\n\n\n\n
Vielleicht:<\/p>\n\n\n\n
Graph Client\nCheckpoint Store\nState Model\nRenderer\nCommand Handler\n<\/code><\/pre>\n\n\n\nDas ist der Punkt, an dem Refactoring nicht kosmetisch ist.<\/p>\n\n\n\n
Es wird funktional.<\/p>\n\n\n\n
Fazit<\/h2>\n\n\n\n
Ein Skript h\u00f6rt nicht auf, ein Skript zu sein, weil es viele Zeilen hat.<\/p>\n\n\n\n
Es h\u00f6rt auf, ein Skript zu sein, wenn es beginnt, Eigenschaften einer Anwendung zu entwickeln:<\/p>\n\n\n\n
State\nLifecycle\nRecovery\nMultiple Interfaces\nPersistence\nVerification\nTests\n<\/code><\/pre>\n\n\n\nDann sollte die Architektur das auch widerspiegeln.<\/p>\n\n\n\n
Nicht mit m\u00f6glichst vielen Patterns.<\/p>\n\n\n\n
Nicht mit unn\u00f6tigen Frameworks.<\/p>\n\n\n\n
Sondern mit klaren Verantwortlichkeiten.<\/p>\n\n\n\n
Die wichtigste Frage bei jedem weiteren Feature lautet deshalb nicht:<\/p>\n\n\n\n
\nWo f\u00fcge ich diesen Code ein?<\/p>\n<\/blockquote>\n\n\n\n
Sondern:<\/p>\n\n\n\n
\nGeh\u00f6rt diese neue Verantwortung \u00fcberhaupt noch in die bestehende Struktur?<\/p>\n<\/blockquote>\n\n\n\n
Wenn diese Frage zu sp\u00e4t gestellt wird, entsteht ein gro\u00dfes Skript.<\/p>\n\n\n\n
Wenn sie rechtzeitig gestellt wird, entsteht ein kleines, gut strukturiertes System.<\/p>\n","protected":false},"excerpt":{"rendered":"
Ein Skript beginnt oft harmlos. Es soll eine klar umrissene Aufgabe erledigen. Eine API aufrufen. Dateien verschieben. Daten bereinigen. Benutzer anlegen. E-Mails verarbeiten. Einen wiederkehrenden manuellen Ablauf automatisieren. Die erste Version ist entsprechend einfach: Das ist v\u00f6llig legitim. F\u00fcr kleine, lineare Aufgaben ist ein einzelnes Skript oft die beste L\u00f6sung. Wenig Struktur, wenig Overhead, kurze […]<\/p>\n","protected":false},"author":1,"featured_media":334,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,33,27,8,25,59,36],"tags":[],"class_list":["post-322","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation","category-methods","category-programming-principles","category-software-architecture","category-software-engineering","category-system-engineering","category-workflow-systems"],"_links":{"self":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/322","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=322"}],"version-history":[{"count":1,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/322\/revisions"}],"predecessor-version":[{"id":323,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/322\/revisions\/323"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/media\/334"}],"wp:attachment":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=322"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=322"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=322"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}