Das hat hier niemand geschrieben.
Die Aufnahme weiß immer noch, was kaputtgegangen ist.

Bei übernommenem Code ist der teuerste Teil eines Fehlers nicht die Änderung. Es ist die Suche nach der Stelle, an die sie gehört – in einem System, dessen Gründe mit den Menschen gegangen sind, die sie hatten.

Das Problem

Ein Symptom in unbekanntem Code kann von vier verschiedenen Stellen stammen, und die einzige Möglichkeit, drei davon auszuschließen, besteht darin, alle vier zu überprüfen. Das ist mühsam, schwer im Hinblick auf eine Roadmap zu rechtfertigen und wird daher oft stillschweigend vernachlässigt: Ein Bericht, der sich auch nach einem Nachmittag intensiver Suche nicht reproduzieren lässt, wird in der Regel als nicht reproduzierbar und nicht als behoben geschlossen. Auch das Sicherheitsnetz ist meist dünn – ein übernommenes System wird selten mit einer vertrauenswürdigen Testsuite geliefert –, sodass selbst eine Änderung, die korrekt erscheint, nicht auf ihre Unbedenklichkeit geprüft werden kann. Und genau der Kontext, der all dies erklären würde – warum dieser Branch existiert und womit der vorherige Maintainer gearbeitet hat –, fehlte bei der Übergabe.

Wie Snag hilft

Der Versuch ist gestuft statt einmalig, und das zählt am meisten, wenn die Antwort nicht offensichtlich ist. Ein günstiger erster Durchlauf liest das Erfasste und entscheidet, ob sich das überhaupt im Code beheben lässt, sodass für den Ausfall eines Drittanbieters kein echter Aufwand entsteht. Was das übersteht, geht in eine Sandbox, die zu dem Stack passt, den das Repository tatsächlich verwendet: Dort kann der Agent den Code durchsuchen und die aufgezeichnete Sitzung Schritt für Schritt zurückgehen, um den Fehler geschehen zu sehen – das ist der Schritt, der aus einem Symptom einen Ort macht. Ist eine Meldung schwerwiegend, ist die Zuversicht der Triage gering, oder gibt es keinen naheliegenden Codebereich, in dem man suchen könnte, gibt die Pipeline sie an ein leistungsfähigeres Modell weiter, statt die erste plausible Antwort zu akzeptieren; Belege und Sandbox bleiben dieselben, und es zählt so oder so als ein Fix-Lauf. Bevor irgendetwas davon Sie erreicht, prüft dann ein unabhängiger Durchlauf die Änderung gegen die Belege und kann sie zur Überarbeitung zurückschicken.

Was Sie zurückbekommen

Eine Änderung, die mit ihrer Begründung und den dazugehörigen Beweisen einhergeht, ist in einem System, von dem niemand ein vollständiges Modell besitzt, etwa so viel wert wie die Änderung selbst. Auch Reviews werden nicht verworfen: Die von Ihrem Team vorgenommenen Korrekturen und die Korrekturen Ihrer Reviewer werden zu einem Bestandteil, auf den spätere Versuche im selben Arbeitsbereich zurückgreifen können. Wenn also in diesem Bereich ein zweites Mal etwas nicht funktioniert, basiert der Versuch auf den Entscheidungen Ihres Teams und nicht auf dem Nichts. Ohne menschliches Eingreifen ist keine Zusammenführung möglich, und gerade bei übernommenem Code ist dies der entscheidende Faktor: Die Beurteilung eines Systems, das Sie noch kennenlernen, obliegt denjenigen, die damit arbeiten müssen.

Fragen, die die Leute tatsächlich stellen

Unser Stack ist alt und etwas ungewöhnlich. Kommt der Sandkasten damit zurecht?

Teilweise, und hier liegt der entscheidende Punkt. Wenn der Stack erkannt wird, wird die Sandbox entsprechend erstellt – Abhängigkeiten werden installiert, Ihr Test-Runner ist eingerichtet – und die Änderung wird anhand Ihrer Testsuite überprüft, bevor ein Lösungsvorschlag unterbreitet wird. Andernfalls liest und durchsucht der Agent den Code dennoch und schlägt eine Korrektur vor; was er jedoch noch nicht kann, ist, Ihre Tests in der Sandbox auszuführen, daher liegt die Überprüfung wieder bei Ihnen.

Was hindert es daran, uns eine plausible Lösung an der falschen Stelle zu präsentieren?

Zwei Prüfungen muss sie zuerst bestehen. Ihre eigenen Tests müssen, wo es welche gibt, bestanden sein, bevor überhaupt etwas geöffnet wird. Und eine unabhängige Durchsicht liest die vorgeschlagene Änderung gegen die erfassten Belege: Sie kann zustimmen, mit konkreten Anmerkungen eine Überarbeitung verlangen oder den Ansatz ganz verwerfen und die Meldung zurück in die Triage schicken. Diese Schleife hat eine feste Obergrenze, sodass eine Meldung, die sie nicht klären kann, vor einem Menschen landet, statt sich weiter im Kreis zu drehen.

Landet unser Quellcode am Ende irgendwo in einem Modell?

Nein. Die Arbeit passiert in einer privaten Kopie des Repositorys, und diese Kopie wird nach dem Lauf gelöscht. Aufbewahrt werden die Belege aus der Meldung und die Historie dessen, was geöffnet wurde – niemals Ihr Quellcode –, und nichts aus Ihrem Code wird zum Training eines Modells verwendet. Spätere Versuche werden mit Ihrer Codebasis zwar besser, aber indem sie in Ihren eigenen zusammengeführten Korrekturen nachschlagen, statt aus ihnen zu lernen: je Arbeitsbereich, und niemals arbeitsbereichsübergreifend.

Woher diese Details stammen

Diese Seite enthält keinerlei Angaben zu anderen Produkten – alle Informationen stammen von Snag. Ist etwas veraltet? Schreiben Sie eine E-Mail an admin@dvcllc.io, und wir korrigieren es.