clowdr.devalpha
arrow_backZurück zum Logbook
EngineeringPositionRobert Trippler

Das Werkzeug ist nicht der Architekt: die Engineering-Entscheidung verantworten

Clowdrs Engineering-Verantwortung auf Architektur, generierten Code, Verhaltensprüfungen, Integration und eine wartbare Übergabe anwenden.

2 Min. Lesezeit
Das Werkzeug ist nicht der Architekt: die Engineering-Entscheidung verantworten
Primärer Practice Area
Engineering
Editorial Format
Position
Artikelautor
Robert Trippler
Veröffentlicht
Aktualisiert
Zusätzliche Practice Areas
  • Production & Verification

Ein Beitrag braucht eine verantwortliche Person im Engineering, die erklären kann, warum er ins Spiel gehört, und ihn bei Änderungen am umgebenden System anpassen kann. Diese Anforderung gilt bei jeder Werkzeugwahl, auch wenn ein Agent den gesamten Patch schreibt.

Clowdr verlangt, dass Contributors ihre Arbeit erklären, überarbeiten, integrieren, prüfen und übergeben können. Diese Position überträgt die Regel auf Code. Sie behauptet nicht, dass ein bestimmtes Werkzeug den Projekterfolg bestimmt.

Die Grenzen vor Annahme des Patches verantworten

Benennt das Verhalten, das die Aufgabe liefern muss, und die Systeme, die sie ändern darf. Erklärt, wo Zustand liegt, wie Fehler behandelt werden und von welchen bestehenden Annahmen die Änderung abhängt. Die Erklärung soll einem anderen Contributor spätere Anpassungen ermöglichen.

Bei einer hypothetischen Änderung am Speichersystem muss die verantwortliche Person erklären, wann Daten geschrieben werden, was bei einer Unterbrechung geschieht und wie ein älterer Spielstand gelesen wird. Eine generierte Umsetzung, die einmal funktioniert, entscheidet diese Fragen nicht.

Kann die Person den Patch nicht erklären, pausiert die Annahme. Vereinfacht ihn, untersucht das relevante Verhalten oder ersetzt die Umsetzung, bis sie verantwortet werden kann. Die Aufgabe weiterzugeben überträgt die Verantwortung nicht an das Werkzeug.

Das Verhalten prüfen, auf das das Spiel angewiesen ist

Nutzt Prüfungen, die ein Scheitern des zugesagten Verhaltens aufdecken können. Konzentriert automatisierte Tests auf relevante Grenzen und Fehlerfälle. Prüft anschließend den integrierten Spielerpfad, in dem die Änderung wirkt.

Unit-Tests belegen nicht den vollständigen Build Proof. Der Release Candidate muss auf jeder angegebenen Plattform starten, laufen und den kritischen Pfad ohne offene Release Blockers abschließen. Haltet Prüfungen, Build und Bedingungen, Befund sowie Grenzen der Abdeckung fest.

Ein Speichertest kann korrekte Daten beim Schreiben und Lesen bestätigen, während die Prüfung im Build einen Menüpfad findet, der den falschen Slot lädt. Behandelt das als unterschiedliche Nachweise und behebt den Fehler, bevor das relevante Verhalten als bereit gilt.

Eine wartbare Übergabe hinterlassen

Haltet die Änderung mit Umfang, Entscheidungen, Prüfungen und bekannten Grenzen in der Versionsverwaltung fest. Klärt wesentliche Quellen, Abhängigkeiten, Lizenzen und Credits. Dokumentiert wesentliche AI-Unterstützung oder bewussten Verzicht gemäß der AI Production Note des Projekts.

Der nächste Contributor soll die verantwortliche Person finden, eine relevante Prüfung reproduzieren und offene Unsicherheiten erkennen können. Undurchsichtige Komplexität, die niemand überarbeiten kann, ist nicht allein deshalb verantwortete Arbeit, weil sie kompiliert.

Der Clowdr-AI-Standard definiert die gemeinsame Regel; How We Ship erklärt die Release-Nachweise. Nutzt das Werkzeug, das die Arbeit unterstützt, und verantwortet anschließend die Engineering-Entscheidung, bei der es geholfen hat.

Datenschutz-Auswahl

Cookies und Messung

Wir nutzen notwendige Speicherung, um deine Auswahl zu merken. Analytics- und Marketing-Speicherung bleiben aus, bis du sie erlaubst. Tracking-Tools sind noch nicht eingebaut, aber diese Auswahl ist bereits fuer Google Consent Mode v2 vorbereitet.