Eine Erweiterung für mehrere Browser ändern, ohne Geheimnisse preiszugeben oder gespeicherte Daten zu beschädigen

## Zuerst die betroffene Schicht der Erweiterung und ihre Regeln ermitteln Ermitteln Sie vor einer Codeänderung die betroffene Schicht: Hintergrundlogik, Benutzeroberfläche, gemeinsame Hilfsprogramme, Browserdeklarationen, Erstellungswerkzeuge, Tests oder Aktualisierungen gespeicherter Zustände. Lesen Sie vor der Bearbeitung die nächstgelegenen schichtspezifischen Anweisungen; Dateien zur Arbeitsablaufautomatisierung enthalten häufig zusätzliche Verknüpfungen und Regeln für die Zusammenführungswarteschlange. Verwenden Sie die vom Repository verwaltete Laufzeitumgebung und das Hüllprogramm der Paketverwaltung. Bewahren Sie die Konfiguration in der vorgesehenen lokalen Umgebungsdatei und niemals im versionierten Quelltext auf. Bevorzugen Sie für jede neue Implementierungsdatei die derzeit verwendete typisierte Sprache; ältere untypisierte Dateien dürfen bestehen bleiben, bis eine angeforderte Änderung ihre Umwandlung rechtfertigt. Verwenden Sie das jeder Dateifamilie zugewiesene Formatierungsprogramm. Das Codeformatierungsprogramm ist für typisierte Dateien und Komponentendateien zuständig, während das Formatierungsprogramm für strukturierte Daten Paket- und Konfigurationsdaten bearbeitet. Führen Sie vor der Übergabe die Formatierung geänderter Dateien sowie Prüfungen statischer Typen, des Quelltextstils und zyklischer Abhängigkeiten aus. Halten Sie Funktionen auf eine Aufgabe ausgerichtet, verringern Sie Verschachtelungen durch frühzeitige Rückgaben, entfernen Sie wiederholte Logik nur, wenn die Auslagerung die Zuständigkeit verdeutlicht, und hinterlassen Sie weder Diagnoseprotokollierung noch auskommentierten Code. ## Geheimnisse lokal halten und Richtlinien nach Abhängigkeitsänderungen neu erzeugen Behandeln Sie API-Zugangsdaten, Überwachungsendpunkte, Testkennwörter und Signaturmaterial als lokale Geheimnisse. Stellen Sie dokumentierte Platzhalter bereit, schreiben Sie jedoch niemals echte Werte fest und nehmen Sie keine vertraulichen Zustände in Diagnoseprotokolle auf. Jedes Hinzufügen, Aktualisieren oder Entfernen einer Abhängigkeit ist eine Änderung der Lieferkette. Führen Sie die gesamte Abfolge aus: 1. Aktualisieren Sie die Paketdeklaration und die Sperrdatei. 2. Entfernen Sie Dubletten aus der Sperrdatei mit dem unterstützten Befehl. 3. Berechnen Sie die Positivliste der Pakete, die Installationsskripte ausführen dürfen, neu. 4. Erzeugen Sie die Zugriffsbefugnisrichtlinien neu, welche den Zugriff von Abhängigkeiten auf Wirts-APIs beschränken. 5. Erzeugen Sie die Drittanbieterkennzeichnung neu. 6. Erstellen und testen Sie mit aktivierter Sicherheitsrichtlinie für den Produktivbetrieb. Nehmen Sie alle erzeugten Richtlinien- und Kennzeichnungsänderungen in dieselbe Prüfung auf. Eine Entwicklungsfassung ohne Richtlinien darf zur schnellen Wiederholung verwendet werden, ersetzt jedoch niemals die geschützte Endfassung. Erzeugen Sie plattformabhängige Richtlinien auf der Zielplattform neu, statt sie abzuschwächen, damit die Erstellung gelingt. ## Hintergrund-Controller mit festgelegtem Zustand und Domänenaktionen bauen Verwenden Sie Controller für die Geschäftslogik im Hintergrund und die nachrichtenbasierte Kommunikation zwischen Teilsystemen. Geben Sie für jede gespeicherte Eigenschaft an, ob sie anonym ist, für Diagnoseschnappschüsse oder Zustandsprotokolle verwendet werden darf, dauerhaft gespeichert wird und von der Schnittstelle genutzt wird. Befolgen Sie diese Zustandsregeln: - Exportieren Sie eine Standardzustandsfabrik, die ein neues Objekt zurückgibt, niemals ein gemeinsam genutztes veränderliches Standardobjekt. - Nehmen Sie Konstruktorabhängigkeiten über ein einziges benanntes Optionsobjekt statt über Positionsargumente entgegen. - Modellieren Sie Domänenaktionen wie Hinzufügen, Entfernen, Genehmigen oder Ablehnen; vermeiden Sie allgemeine Feldsetzmethoden. - Speichern Sie nur den erforderlichen Zustand und leiten Sie Anzahlen, Kennzeichen und Projektionen über exportierte Auswahlfunktionen ab. - Validieren Sie Aktionseingaben vor der Zustandsaktualisierung. - Implementieren Sie die Lebenszyklusbereinigung für Zeitgeber, Abonnements, Listener und Nachrichtenkanäle und delegieren Sie anschließend an die Bereinigung der Elternklasse. Halten Sie Controller-Quelltext, Typen, direkt zugeordnete Tests, Registrierung und betroffene Auswahlfunktionen synchron. Eine Änderung der Zustandsstruktur erfordert außerdem einen nummerierten Aktualisierungsschritt. ## Code in die zuständige Schicht legen und verbundene Dateien mitändern Legen Sie wiederverwendbare Schnittstellenkomponenten zusammen mit ihren Stilen, Typen, Tests, Beispielszenarien, ihrer Dokumentation und ihrer öffentlichen Exportdefinition ab. Legen Sie seitenspezifische Komponenten in der Seitenschicht, reine Hintergrundhilfen beim Hintergrundcode und tatsächlich gemeinsam genutzte Hilfsprogramme, Konstanten und Typen in gemeinsamen Modulen ab. Prüfen Sie bei Verhaltensänderungen die direkt gekoppelten Dateien: - Änderungen an Controllern können Tests, Typen, Registrierung und Zustandsaktualisierungen erfordern. - Änderungen an Komponenteneigenschaften können Tests, Beispielszenarien, Stile, Dokumentation und Exporte erfordern. - Änderungen am globalen Zustand können Auswahlfunktionen und verwendende Komponenten erfordern. - Änderungen an Erstellung oder Browserdeklarationen können zielspezifische Testvorrichtungen und durchgängige Testabdeckung erfordern. Kopieren Sie gemeinsame Logik nicht nur, um die Wahl eines Zuständigen zu vermeiden. Verschieben Sie sie in die engste gemeinsame Schicht, verwenden Sie bei Bedarf Abhängigkeitsinjektion und lösen Sie zyklische Importe auf, statt eine erweiterte Ausnahmeliste hinzunehmen. ## Jedes Browserziel und jeden Funktionsschalter getrennt bauen und testen Unterhalten Sie für jede unterstützte Erzeugung von Browserdeklarationen einen eigenen Erstellungs- und Testpfad. Berücksichtigen Sie Unterschiede wie dauerhafte Hintergrundseiten gegenüber Service Workern, Berechtigungsmodelle und die Verfügbarkeit von Namensräumen. Verwenden Sie im gemeinsamen Code die browserübergreifende API-Abstraktion. Isolieren Sie unvermeidbare Zielunterschiede in einer kleinen Kompatibilitätsschicht, statt Bedingungen über Funktionen zu verteilen. Funktionsschalter müssen ausdrückliche Erstellungseingaben sein: - Verwenden Sie die dokumentierte lokale Konfiguration für reproduzierbare Entwicklung. - Verwenden Sie Umgebungsüberschreibungen mit einem einzelnen Befehl für isolierte Versuche. - Verwenden Sie eine lokale Deklarationsüberschreibung nur für Prüfszenarien entfernter Funktionsschalter. - Erstellen und testen Sie genau die Kombination aus Ziel und Funktionsschaltern, die ausgeliefert wird. Nennt der Benutzer keinen Browser, verwenden Sie das dokumentierte Standardziel des Projekts. Nennt die Anfrage ein Ziel, wählen Sie die passenden Entwicklungs-, Produktiv- und End-to-End-Befehle, statt die Kompatibilität aus einer anderen Erstellung abzuleiten. ## Oberflächenkomponenten schreiben und erst nach dem Messen optimieren Verwenden Sie Funktionskomponenten und Hooks, zerlegen Sie Eigenschaften an der Grenze, halten Sie rein lokalen Zustand lokal und nutzen Sie die gemeinsame Zustandsschicht nur für funktionsübergreifende Daten. Für korrekte und leistungsfähige Darstellung: - Verwenden Sie stabile Domänenkennungen als Schlüssel für dynamische Listen, niemals Positionen im Datenfeld. - Berechnen Sie abgeleitete Anzeigewerte während der Darstellung, statt sie über einen Effekt in den Zustand zu kopieren. - Memoisieren Sie aufwendiges Sortieren, Filtern oder Zusammenfassen nur, wenn die wiederholte Arbeit erheblich ist. - Stabilisieren Sie Rückruffunktionen, die an memoisierte Kindkomponenten übergeben werden, wenn wechselnde Referenzen erneute Darstellungen verursachen. - Definieren Sie tatsächlich statische Objekte und Stile außerhalb der Komponente. - Ziehen Sie für große Listen eine Virtualisierung erst nach Messung der Darstellungskosten in Betracht. Kopieren Sie vor dem Sortieren, wenn Eingaben unveränderlich sind. Untersuchen Sie zuerst häufig dargestellte oder rechenintensive Komponenten; fügen Sie einfachen, selten dargestellten Komponenten ohne Nachweis keine Memoisierung hinzu. ## Fehler mit einem fehlschlagenden Test nachstellen, beheben und erneut testen Fügen Sie bei einem Fehler zuerst einen gezielten Test hinzu, der das Versagen reproduziert, führen Sie ihn erfolglos aus, implementieren Sie die kleinste Korrektur, führen Sie ihn erfolgreich aus und prüfen Sie anschließend den direkt betroffenen Umfang. Legen Sie Einheitentests beim Quelltext ab und testen Sie Verhalten über öffentliche Schnittstellen statt über private Methoden. Verwenden Sie Integrationstests für Grenzen zwischen Teilsystemen. Verwenden Sie End-to-End-Tests für reale Browserabläufe und erstellen Sie zuerst das zugehörige Prüfartefakt. Während der Wiederholung kann eine schnellere ungeschützte Fassung zulässig sein; die abschließende Prüfung muss die Sicherheitsrichtlinie für den Produktivbetrieb und das angeforderte Browserziel verwenden. Wenn eine visuelle Prüfung ausdrücklich angefordert wurde: 1. Starten Sie die tatsächliche Testumgebung der Erweiterung. 2. Prüfen Sie vor einer Aktion den aktuellen Bildschirm. 3. Durchlaufen Sie den Benutzerablauf mit den Browsersteuerelementen. 4. Erfassen Sie eine Bildschirmaufnahme oder eine Beschreibung des Endbildschirms als Nachweis. 5. Bereinigen Sie die Testsitzung auch nach einem Fehlschlag. Ist das erforderliche visuelle Werkzeug nicht verfügbar, melden Sie diese Einschränkung und behaupten Sie keine visuelle Prüfung allein aufgrund der Codeprüfung. Prüfen Sie Änderungen an Schnappschüssen vor ihrer Annahme; aktualisieren Sie einen Schnappschuss nur bei einer beabsichtigten Verhaltensänderung. ## Bei geänderter Form gespeicherter Daten ein nummeriertes Upgrade schreiben Erstellen Sie bei jeder Änderung der dauerhaften Zustandsstruktur eine nummerierte Aktualisierung. Erzeugen Sie sie mit dem Repository-Werkzeug, damit Reihenfolge und Registrierung einheitlich bleiben. Eine Aktualisierung muss: - ältere, unvollständige und teilweise beschädigte Eingaben sicher annehmen; - die Eingabe klonen und ein neues Zustandsobjekt zurückgeben, statt den Wert des Aufrufers zu verändern; - nur den eigenen Versionsbereich und die eigenen Eigenschaften umwandeln; - die Zielversion ausdrücklich festhalten; - nicht zugehörige Benutzerdaten bewahren. Testen Sie repräsentative alte Zustände, fehlende Felder, fehlerhafte optionale Werte, Idempotenzanforderungen und die genaue neue Ausgabe. Führen Sie sowohl den Aktualisierungstest als auch die Controller- oder Funktionstests aus, welche den aktualisierten Zustand verwenden. ## Fehler nach Art einordnen und beheben, ohne Prüfungen abzuschalten Lesen Sie den ersten verwertbaren Fehler, bevor Sie die Umgebung ändern. Ordnen Sie ihn einem Fehler bei Formatierung, Typen, Abhängigkeiten, Zugriffsbefugnisrichtlinien, Browsererstellung, Testdaten, veralteten Artefakten, Ports oder zyklischen Importen zu und führen Sie dann die engste Diagnose für diese Klasse aus. Wenn ein zuvor erfolgreicher Test nach der Änderung fehlschlägt, ermitteln Sie, ob die Implementierung eine Regression enthält oder sich das erwartete Verhalten absichtlich geändert hat. Aktualisieren Sie den Test nur im zweiten Fall und dokumentieren Sie den Verhaltensgrund. Prüfen Sie bei End-to-End-Fehlern, ob die richtige und aktuelle Testfassung vorhanden ist, verwenden Sie Diagnoseausgaben und lassen Sie den Browser nur während einer aktiven Untersuchung laufen. Erzeugen Sie bei Richtlinienfehlern die Richtlinie aus den deklarierten Abhängigkeiten und dem Wirtszugriff neu; deaktivieren Sie die Durchsetzung nicht dauerhaft. Entfernen Sie Zwischenspeicher, Erstellungsausgaben, installierte Pakete, Browserdaten oder Schnappschüsse erst, nachdem Sie das genaue Ziel ermittelt und die sichere Neuerzeugung bestätigt haben. Verwenden Sie eine umfassende Bereinigung nicht als ersten Schritt der Fehlerbehebung. ## Commits, Pushes und Prüfanfragen nur auf ausdrücklichen Wunsch ausführen Ändern Sie weder die Repository-Konfiguration noch führen Sie zerstörerische Befehle der Versionsverwaltung aus. Stagen, committen oder pushen Sie nicht und öffnen Sie keine Prüfanforderung, sofern der Benutzer die jeweilige konkrete Aktion nicht ausdrücklich verlangt hat. Bei erteilter Autorisierung: - Stagen Sie nur Dateien, die zur angeforderten Änderung gehören. - Formatieren und testen Sie den geänderten Bereich vor dem Commit. - Verwenden Sie die strukturierte Commit-Konvention des Repositorys. - Pushen Sie nur, wenn ein Push verlangt wurde. - Öffnen Sie eine Prüfanforderung als Entwurf, sofern der Benutzer nicht ausdrücklich den Status „bereit“ verlangt hat. - Befolgen Sie die Prüfungsvorlage und blenden Sie nicht zutreffende Abschnitte vollständig aus. Abschnitte zu manuellen Tests müssen menschliche Handlungen und sichtbare Ergebnisse statt automatisierter Quelltextprüfungen oder Testbefehle beschreiben. Fügen Sie für sichtbare Schnittstellenänderungen Vorher-Nachher-Nachweise hinzu, erläutern Sie nicht offensichtliche Entscheidungen, verknüpfen Sie zugehörige Arbeiten und kennzeichnen Sie bei Bedarf benutzerrelevante Änderungshinweise. Beantworten Sie während der Prüfung Rückmeldungen und fügen Sie Folge-Commits hinzu, statt bereits geprüfte Historie umzuschreiben. Verlangen Sie vor der Zusammenführung geklärte Unterhaltungen, Genehmigungen, erfolgreiche Automatisierung und den vom Repository erwarteten Squash-Titel. Schließen Sie mit einer angemessenen Prüfliste ab: Formatierung geänderter Dateien, Typen, zyklische Abhängigkeiten, gezielte Tests, betroffene Erstellungen, zugehörige Dateien, Dokumentation, produktive Zugriffsbefugnisrichtlinien bei geänderten Abhängigkeiten und echte visuelle Nachweise, wenn sie angefordert wurden.