Was sind einige bewährte Methoden vor dem Einchecken von Quellcode? [geschlossen]

Mein Team verwendet Team Foundation Server für die Quellcodeverwaltung. Heute habe ich einige Fehler behoben und eine Testanwendung erstellt, bevor ich sie eingecheckt habe. Ich habe jedoch vergessen, Code zu kommentieren. (Dieser Code hat die Benutzeroberfläche ein wenig seltsam gemacht.)

Ich möchte wissen, welche guten Praktiken es gibt, bevor ich Code einchecke - ich möchte diese Art von Fehler nicht noch einmal machen.

Eine Sache, die ich mir angewöhnt habe, ist immer die Unterschiede jeder Datei zu prüfen, die ich einchecken möchte, kurz bevor ich sie einchecke.

Sie sollten niemals auskommentierten Code einchecken. Wenn Sie Code haben, der vor dem Einchecken auskommentiert werden muss, machen Sie es falsch.

Wie für Regeln:

1. Bekomme das neuste
2. Behebung von Zusammenführungskonflikten

3. Bauen

   3.1 Beheben Sie Build-Fehler

4. Führen Sie Tests durch

   4.1 Defekte Tests beheben

5. Gehe zu 1 (bis nichts mehr zu bekommen ist)

Erst einchecken, wenn alle Schritte abgeschlossen sind.

Siehe Check-in-Tanz .

Andere gute Praktiken:

• Überprüfen Sie die Liste der einzucheckenden Dateien, um sicherzustellen, dass es sich um die erwarteten Dateien handelt.
• Überprüfen Sie die Änderungen für jede Datei (Löschen / Hinzufügen / Vergleichen).

Ich versuche hier nicht, zu sehr ein Pantsweasel zu sein, aber die Annahme in dieser Frage (und alle bis auf eine der Antworten) gilt hauptsächlich für zentralisierte VCS wie TFS, SVN, Perforce usw.
Gut genug, es ist was das OP verwendet.

Auf der anderen Seite sollten Sie jedoch bei der Verwendung von DVCS (wie Mercurial und Git) in der Regel nicht auf das Einchecken warten, und die meisten in den Antworten genannten Dinge - wie Unterschiede, Neueste abrufen, Zusammenführen usw. - sind nicht erforderlich . Sogar Dinge wie Codeüberprüfungen und -tests sind nach dem Einchecken besser durchzuführen (allerdings möglicherweise vor dem Pushen, je nachdem ...)
. Natürlich ist es auch gut, das Einchecken zu kommentieren ...

Drei Dinge, die ich in anderen Antworten nicht gesehen habe:

Neue Dateien einschließen

• Suchen Sie nach neuen Dateien, die nicht in Ihrer Änderungsliste enthalten sind
• Kann für SCMs wie Perforce spezifisch sein - Sie müssen ihm alles mitteilen, was sich in Ihrer Änderung befindet.

Unveränderte Dateien wiederherstellen

• Ich hasse es, wenn ich mir die Änderungen anderer Leute ansehe und es eine Änderungsliste mit neun Dateien gibt, von denen jedoch nur drei geändert wurden.
• Ich stelle auch Dateien mit Leerzeichen oder anderen bedeutungslosen Änderungen wieder her.

Überprüfen Sie Ihr eingereichtes Commit

• Stellen Sie sicher, dass der Build nach dem Festschreiben grün bleibt.
• Früher hatte ich eine zweite Maschine, die ich nach meinen Commits synchronisierte, erstellte und ausführte. Wenn also etwas schief ging, konnte ich leicht hineinspringen und es reparieren.

Zwei Dinge, wenn ich Git benutze:

Atomic Commits:

• Stellen Sie nur einzelne Funktionsänderungen für das Festschreiben bereit.
• Machen Sie Commits so klein wie möglich. Vereinfachen Sie das Patchen, Zurücksetzen und Verstehen.
• Ich git add --patchteile meine Änderung bei Bedarf in mehrere Teile auf.

Ansichtsunterschiede beim Zusammenfassen

• Ich checke immer bei ein, git commit --verbosedamit ich einen Unterschied zwischen meinen Änderungen sehen kann, während ich meine Commit-Nachricht eingebe. (Oder ich benutze mein gepatchtes Git-Vim , um den Unterschied zu zeigen.)
• Dies macht es viel einfacher, Ihre Änderungen durchzugehen und das gesamte Commit zu beschreiben. Gelegentlich bemerke ich in dieser Phase unbeabsichtigte Änderungen. (Wenn Sie Ihre Änderung beschreiben, können Sie darüber nachdenken.)

Einige bewährte Methoden, die ich auf den Servern meines Teams durchsetze, sind ziemlich einfach. Bevor Sie einchecken, sollten Sie immer die neueste Version erhalten und einen lokalen Build ausführen, um sicherzustellen, dass niemand anderes etwas überprüft hat, mit dem Sie in Konflikt geraten. Achten Sie außerdem auf Codekonflikte auf Ihrem lokalen Computer, nicht auf dem Server. Nachdem bestätigt wurde, dass Ihr Code mit dem neuesten heruntergeladenen Code erstellt wurde und ordnungsgemäß funktioniert, können Sie mit dem nächsten Schritt fortfahren. Führen Sie alle automatischen Tests durch und beginnen Sie dann mit dem Einchecken, um sicherzustellen, dass sie weiterhin ordnungsgemäß funktionieren. Dann, um ganz sicher zu gehen, melden Sie sich bitte erneut an.

Als TFS-Administrator ist es möglich, Kommentare zu allen Eincheckvorgängen zu erzwingen. Ich würde empfehlen, immer Check-in-Kommentare für Ihre Arbeit einzutragen, unabhängig davon, ob sie erzwungen wird oder nicht. Wenn Sie die Option dazu haben, erzwingen Sie es. Stellen Sie sicher, dass die Kommentare zumindest eine allgemeine Zusammenfassung dessen sind, was Sie seit dem letzten Einchecken Ihres Codes geändert haben. Auf diese Weise können Sie bei einem Fehler die Eincheckvorgänge durchsehen und ungefähr sehen, was war in diesem Check-in geändert. Dies erleichtert das Debuggen eines fehlerhaften Builds erheblich.

Wenn Sie über TFS-Administratorrechte verfügen, müssen Sie beim Einchecken fortlaufende Builds erzwingen (um sicherzustellen, dass alle anderen sofort wissen, ob das Einchecken zu Problemen führt). Außerdem können Sie den Server so einrichten, dass entweder ein gated Check-in durchgeführt wird ( Wenn der eingecheckte Code den Build unterbricht, lehnt der Server ihn ab, oder Sie können ihn einfach einen Fehler erstellen lassen und ihn jedem zuweisen, der den Build gebrochen hat.

Es gibt ein paar andere Optionen, die Sie aktivieren oder deaktivieren können, um alles in Ordnung zu halten, oder um Ihrem TFS-Administrator vorzuschlagen, sie zu aktivieren, um die Dinge schön und sauber zu halten ... aber sie werden größtenteils bevorzugt

Suche und ersetze Schimpfwörter ;-)

Wenn Sie von Windows aus einchecken, prüfen Sie, ob Ihr Code nicht über diese unsichtbaren ^ M-Zeichen verfügt - Editoren in UNIX geben häufig Fehler / Warnungen an.

Versuchen Sie auch, Tabulatoren zu ersetzen - verschiedene Benutzer sehen Tabulatoren unterschiedlich, einige mit 4 Leerzeichen, andere mit 8 und nicht gut für die Lesbarkeit des Codes.

Bester Ansatz IMHO besteht darin, Ihren Code von einem vordefinierten Skript anhand der Codierungsrichtlinien Ihrer Organisation überprüfen zu lassen. Viele Versionsverwaltungssysteme verfügen über diese Funktionalität.

In meiner Firma verwenden wir Check-in-Bewertungen. Diese müssen nicht detailliert sein, aber wenn Sie nur jemandem die Unterschiede in Ihrer Änderungsliste zeigen und sie durchsprechen, wird manchmal der seltsame Tippfehler hervorgehoben, den Sie beim Testen verpasst haben.

Unser Quellcodeverwaltungsserver ermöglicht Ihnen das Einchecken nur, wenn Sie den Namen des Überprüfers in den Kommentaren notieren (in der Form! Initialen, z. B.! BW, wenn Bruce Wayne Ihre Überprüfung durchgeführt hat). Der Prüfer erhält eine E-Mail, in der er darauf hingewiesen wird, dass er bei der Prüfung mitgewirkt hat. Dies ist offen für offensichtliche Ausbeutung, scheint aber ziemlich gut zu funktionieren.

Wann immer möglich, möchte ich einen Check-in mit einem Arbeitselement verknüpfen. Dies gibt Ihnen einige kontextbezogene Informationen darüber, warum dies geändert wurde, und nicht nur darüber, was geändert wurde. TFS verfügt über ein ziemlich anständiges System zur Nachverfolgung von Arbeitselementen, daher ist dies beim Einchecken eher trivial.

(Dies ist zusätzlich zur Überprüfung der Unterschiede meiner Änderungen)

Eine kleine Sache, die ich mache, ist, keine Dateien einzuchecken, die sich nicht wirklich geändert haben. Diese Dateien wurden möglicherweise versehentlich geändert oder waren an Umgestaltungen beteiligt, die entweder rückgängig gemacht oder anderweitig in Frage gestellt wurden.

Auf diese Weise enthält Ihr Änderungssatz (der einem Arbeitselement zugeordnet ist) genau die Dateien, die zur Erfüllung des Arbeitselements erforderlich sind.

Um alle Antworten hier zu kombinieren und eine vollständige Checkliste zu erstellen

1. [einchecken / auschecken] Sie sollten nicht direkt in den Stream einchecken, in dem andere arbeiten. Sie sollten eine Stream-Strategie haben: zB pro Entwickler einen Stream, in dem Sie unabhängig ein- und auschecken können, ohne andere zu stören: Ihre Arbeit wird sei sicher aber in deinem eigenen entwicklungsstrom so [nur in deinem eigenen entwicklungsstrom]. Bei jedem Einchecken verknüpfen Sie es mit einem Änderungsdatensatz, sodass Ihre Änderungen dem Änderungssatz entsprechen (sodass Sie einzelne RFCs / Bugs usw. verteilen können, ohne "alles" liefern zu müssen).

2. [dann mit deinem Team-Stream zurücksetzen] bedeutet, dass du die Änderungen von anderen in deinem eigenen Stream erhältst. Während dieses Vorgangs können Sie im Zusammenführungsdialog alle "Unterschiede" sehen und sie durchgehen oder ... wenn es Tausende gibt und / oder Sie nicht Code verwenden, sondern auch zB Datenmodelle / Siebel-Projekte usw. ... sich entweder darauf verlassen Nicht triviale Zusammenführungen, trivial-automatische und triviale manuelle Zusammenführungen, die letzte Kategorie enthält die schwierigen. Denken Sie daran, dass Sie immer noch in Ihrem eigenen Stream arbeiten.

3. Wenn alles in Ordnung ist, checken Sie alle Änderungen ein, die Sie gerade vom Team-Stream erhalten haben: Ihr eigener Stream ist jetzt auf dem neuesten Stand

4. [deliver] übermittle jetzt deine Arbeit an den Team-Stream. Wenn Sie nicht alles liefern möchten, können Sie auch z. B. 1 spezifischen RFC mit diesen spezifischen Versionen von Dateien oder eine Reihe von RFCs / behobenen Fehlern auswählen.

5. [test deliver] sollte gehen aber ok da die chance besteht, dass sich zwischenzeitlich jemand ändert kannst du testen ob deine arbeit mit den neuesten änderungen im team stream klappt. Mit den gleichen Zusammenführungsdialogen, die Unterschiede anzeigen.

6. [Lieferung abschließen] Schließen Sie Ihre Lieferung ab, und Ihre Arbeit befindet sich jetzt im Team-Stream.

Um es komplexer zu machen: Da es immer noch die Möglichkeit gibt, dass die von Ihnen gelieferte Arbeit in Ordnung ist, ABER Sie bereits an einer weiteren Version arbeiten, sollten Sie immer nach der Lieferung eine Baseline erstellen und angeben, von welcher Baseline diejenige für andere Benutzer bevorzugt wird . Das stellt sicher, dass andere Entwickler eine empfohlene und nicht die neueste Version im Stream erhalten (wenn Sie in diesem Szenario arbeiten). Dies ist auch eine dreifache Überprüfung, sodass selbst wenn die neuesten Versionen im Team-Stream "schlecht" sind, sie immer noch nicht diejenigen sind, auf die andere zurückgreifen oder die sie sich ansehen, und Ihr Konfigurationsmanager dann die vorherige Version zur nächsten Version zusammenführen kann, um den Vorgang rückgängig zu machen Ihre Lieferung.

• Die Antwort von Histumness kommt zweimal vor: in Schritt 2 und 6
• Die Antwort von Oded auf Check-in-Tanz: Sie müssen jedoch eine zusätzliche Schicht liefern und beim Ein- und Auschecken neu berechnen, um sicherzustellen, dass Sie isoliert arbeiten und Fehler auch in späteren Phasen jederzeit problemlos behoben werden können
• Die Antwort von Guildsbounty lautet Schritt 2. Für den Build: Es hängt wirklich davon ab, ob Sie einen Build haben ... In meiner Welt haben Sie Eingaben von Datenmodellen, Word-Dokumenten, Anforderungsblättern, Konfigurationsdaten von informatica, siebel, etc .. und ja auch java code, .net code etc ... das sollte sich alles vermischen. Es gibt hier also keinen wirklichen "Build", sondern eine höhere Integration, abhängig davon, ob dieser einzelne Build aus Ihrem "Code" in den Rest des Materials integriert ist, da Sie nicht sicher wissen können, ob es sich um Integrationsmaterial handelt und davon abhängt In ihren Testumgebungen kann es sein, dass kompiliertes Material benötigt wird oder bei höheren Auslieferungen ein anderes Build, weil es etwas von einem anderen Team benötigt.
• Die Antwort von Guildsbounty auf das Kommentieren und Erforderlich: Ich denke, dass jede Umgebung, in der Sie VERSIONS und Changes in Change Sets (und Typ: Defects, RFC, HotFi) nicht integriert haben, noch nicht ausgereift ist. Ich denke, es ist chaotisch, wenn man Release Notes mit der Menge der eingereichten Bugs und Rfcs, die durch Anklicken erreichbar sind, nicht automatisieren kann (da zB Version 1 und Version 3 von hello.c sehr gut ausgeliefert werden könnten, aber Version 2 hätte nicht ausgeliefert werden sollen, da das Zeug in einem späteren Release enthalten sein würde, aber einige Noobs es bereits eingefügt haben. Dies bedeutet also eine manuelle Entscheidung, WENN Sie auch Version 3 von Hallo herausnehmen möchten. c ABER das Entfernen von Version 3 bedeutet, dass Sie auch alle anderen Versionen entfernen müssen, die von diesem RFC / Defekt betroffen sind, damit Sie in der Lage und schnell mit einem Tool sein müssen, das die gesamte Sache entfernt) (auch wenn mehrere Entwickler an Teilen von gearbeitet haben dasselbe RFC), aber zumindest brauchst du Dinge, um darüber zu entscheiden etc ...). Zusätzliche Dokumentation ist immer praktisch, aber durch das Verknüpfen von Änderungssets erhalten Sie den vollen Kreis: eine Version <- ein Änderungsset <- Arbeitselemente <- ein Ticket / RFC / Defekt <- eine Anforderung. Das heißt: Sie wissen, welche Anforderungen vollständig oder vollständig geliefert werden: Eine Anforderung enthält mehrere RFCs oder Bugs oder was auch immer. Der RFC verfügt über mehrere Workitems für mehrere Personen. Dieses Workitem entspricht einer Änderungsmenge, die aus einer Menge von Versionen besteht (z. B. Version 1 und 3 von hello.c im Integrationsdatenstrom, die natürlich NICHT die Versionen 1 sind).
• der kommentar von luis.espinal: dont break the build ist in rebase und deliver noch doppelt geprüft ... es gibt höhere auslieferungen für 'release manager und build meisters', die change sets und baselines als info sehen sollten. "Niemals direkt am Hauptzweig arbeiten" Ja, die Stream-Struktur kann groß oder einfach sein, aber im Wesentlichen: Entwickler haben ihren eigenen Stream, sie liefern ihn an einen Team-Stream, der ihn an einen Release-Stream liefert. -> damit die Lieferungen von allen Teams (zB Dokumentationsteam, Anforderungsteam, Entwicklungsteams,

In Ihrem Beispiel geben Sie an, dass Sie vergessen haben, Code auskommentiert zu haben. Fehler passieren. Das Konfigurationsmanagementsystem, das sich darum kümmert, sollte sich darum kümmern. Es kann wirklich sein, dass z. B. Tausende von Änderungen eingehen und "Builds" und "Integrationen" in einer Hierarchie von Streams auf verschiedenen Servern stattfinden, die zeitlich verkettet und verarbeitet sind. Selbst wenn Ihr auskommentierter Code nach 5 Monaten auf einem Integrationsserver getestet wird, weil Ihr Code in anderen Code und Systemen integriert werden muss, sollte es dennoch möglich sein, Ihren Änderungssatz atomar herauszunehmen und weiterzumachen. Das beste Verfahren liegt also mehr oder weniger auf einer höheren Ebene. Der Gesamtentwurf der Konfigurationsmanagement-Streams sollte sich darum kümmern. Für einzelne Entwickler empfiehlt es sich, den Unit-Test zu validieren. Aber vom großen Bild zu "

Einige der folgenden Punkte gelten je nach SCM mehr als andere (oder in unterschiedlichen Formen).

1. Unterbrechen Sie nicht den Build - überprüfen Sie nur den Code, der kompiliert wird.
2. Kommentieren Sie Ihre Eincheckvorgänge (und möglicherweise Ihre Auscheckvorgänge, wenn Ihr SCM Ihnen diese Option bietet.)
3. Behalte Dinge nicht für längere Zeit unkontrolliert.
4. Checken Sie oft ein (wenn möglich mehrmals täglich).
5. Beschriften Sie sinnvoll.
6. Regelmäßig beschriften.
7. Niemals direkt am Hauptast arbeiten.
8. Jede Produktionsfreigabe muss ein eigenes Label haben (und wenn möglich einen Nur-Lese-Zweig vom Hauptzweig). Wenn möglich, machen Sie dasselbe für UAT / Integration / Pre-Production-Test-Releases.
9. Sie sollten in der Lage sein, aus dem, was sich in Ihrem SCM befindet, und aus einem Etikett genau das zu erstellen, was sich in der Produktion befindet.

ANMERKUNG : Einige der obigen Punkte scheinen ziemlich offensichtlich zu sein, aber Sie würden nicht glauben, wie viele Personen tatsächlich in der Hauptniederlassung arbeiten oder zuerst Änderungen an der Produktion vornehmen und dann manuell Deltas erstellen, um die Versionskontrolle zu aktivieren ... direkt in der Hauptniederlassung. .. und mit Etiketten. Süß wie fermentierte Galle gemischt mit ungewaschenem Achselhöhlen-Saft ... ja, so.

Habe eine persönliche Checkliste. Beginne es leer, wenn du es vermasselst, bei einem Eintrag. Wenn es zur zweiten Natur wird, entfernen Sie es aus der Liste.

Führen Sie die Tests aus. Wenn sie es bestehen, checken Sie es ein. Wenn Sie durcheinander sind und etwas die Tests übersteht, schreiben Sie einen Test.

Wir machen folgendes ...

1. Test - Wir wollen sicherstellen, dass es funktioniert. Zumindest wollen wir wissen, dass es nichts kaputt macht.

2. Code-Überprüfung oder zumindest ein Buddy-Check - Dies ist eine großartige Möglichkeit, um sicherzustellen, dass das Wissen verbreitet wird und die Leute auf dem Laufenden gehalten werden. Es hilft auch, Fehler zu erkennen, bevor Sie Dinge einchecken.

3. Vorabbenachrichtigung senden - Vor dem Einchecken wird eine Vorabbenachrichtigung an die Gruppe gesendet. Der Zweck besteht nicht nur darin, anderen mitzuteilen, welche Dateien oder Bereiche sich ändern, sondern sie werden informiert (falls sie dies bemerken sollten), falls diese Änderungen sie voraussichtlich betreffen.

4. Einige Stunden nach dem Absenden der Vorankündigung wird der Check-in durchgeführt und die Gruppe per E-Mail informiert. Jeder in der Gruppe kann wissen, wann die bestimmte Arbeit an einem Fehler oder einer Funktion abgeschlossen ist.

5. Eine Kopie des Check-in-Hinweises wird in den Fix-Datensatz eingefügt, der dem Fehler oder der Funktion zugeordnet ist. Beim Durchsuchen der Datensätze stellen wir fest, dass es sehr praktisch ist, eine Vorstellung davon zu haben, was die Korrektur / Funktion mit sich brachte.

Führen Sie Ihre Unit-Tests durch, an denen Sie so fleißig gearbeitet haben. Grün ist gut.

Stellen Sie sicher, dass Ihr Code richtig formatiert ist (z. B. für Java: Wählen Sie Ihren Code aus und drücken Sie Strg-Umschalt-F in Eclipse). Seien Sie jedoch vorsichtig, wenn Sie dasselbe für ein gesamtes Dokument tun.

Überprüfen Sie immer, immer, immer , ob die von Ihnen vorgenommenen Änderungen den Build nicht beschädigen. Vor allem kleinere Änderungen, die trivial erscheinen können.

Einmal habe ich eine sehr kleine Änderung vorgenommen, von der ich nicht dachte, dass sie irgendwelche Probleme verursachen würde, kurz bevor ich die Arbeit für das Wochenende verließ. Sicher genug, diese kleine Änderung hat den Build zerstört und es wurden keine nächtlichen Testläufe für unser Projekt durchgeführt. Der Q & A-Chef war darüber nicht allzu glücklich, und das zu Recht.

Suchen Sie nach Teilen Ihrer Änderungen, die als eigenständige Einheiten verwendet werden können.

Bis ich eine funktionierende Korrektur oder Verbesserung des Codes habe, gibt es oft einige Änderungen. Einige von ihnen sind spezifisch für die Verhaltensänderung, die ich anstrebe; andere sind Refactorings, die ich durchgeführt habe, um diese Änderung sauberer zu machen.

Ich ziehe es vor, jedes Refactoring separat mit einer eigenen Änderungsbeschreibung wie folgt einzuchecken:

REFACTORING: Benenne X in Y um

X hat früher Sinn gemacht, weil ... aber jetzt sollte es Y sein. Dies hängt mit der Arbeit für Ausgabe 9 zusammen.

Sobald dann jedes gute Refactoring eingecheckt ist, ist die endgültige Verhaltensänderung oft trivial.

Außerdem wirken sich einige Änderungen auf viele Codezeilen aus, sind aber nicht sehr interessant, während andere Änderungen sehr lokalisiert sind, aber wichtige Auswirkungen haben. Wenn diese Änderungen zusammen eingecheckt werden, kann es schwierig sein, die Unterschiede zu lesen. Also halte ich sie getrennt.

Später, wenn jemand die Änderungshistorie durchliest, ist es offensichtlich, wie die Dinge auf den aktuellen Stand gebracht wurden und warum sie so sind. Es ist auch trivial, meine Verhaltensänderung rückgängig zu machen, da es nicht mit Tonnen von anderen Bearbeitungen zu tun hat.

Tun Sie, was Sie tun würden, wenn Sie etwas zurückgeben, das Sie von jemandem ausgeliehen haben. Stellen Sie sicher, dass es sauber und in gutem Zustand ist. Wenn Sie ein Durcheinander begangen haben, reinigen Sie es, bevor Sie den Code an den Eigentümer zurückgeben (in den meisten Fällen an Ihren Arbeitgeber).

Ich behalte ein lokales HG-Repo für meine Arbeit.

• Immer wenn ich etwas einchecke, schaue ich über das Differential und stelle sicher, dass alle Änderungen akzeptabel sind.
• Ich versuche, das Hauptmerkmal des Eincheckens zu notieren.
• Ich versuche, jede Festschreibungsgröße auf ein Schlüsselmerkmal zu beschränken.

Ich behaupte nicht, dass dies die besten sind, aber sie funktionieren für mich.

Wenn ich Code schreibe, von dem ich weiß, dass er nicht zum Einchecken bestimmt ist, füge ich eine Zeile mit "// TEMP:" und danach mit "// END TEMP." Hinzu. Dies, zusammen mit dem Ausführen von diff vor dem Einchecken, verspricht, dass ich diesen Code nicht versehentlich einchecken werde.

Testen Sie alles, was Sie hinzugefügt oder geändert haben, gründlich. Probieren Sie jeden denkbaren Fall aus, um es zu versuchen. Überlassen Sie das Testen nicht der Qualitätssicherung. Wenn ich jedes Mal ein Sandwich hätte, wenn ich ein paar kleinere Änderungen vorgenommen und dann einige Testfälle aus Sicherheitsgründen ausprobiert hätte und sofort Probleme sah, hätte ich viele Sandwiches. Ich sage normalerweise laut zu mir selbst "Ich bin wirklich froh, dass ich das versucht habe ..."

Sie sagen, die Benutzeroberfläche wurde nach Ihrer Änderung seltsam. Wenn Sie nur das Programm ausgeführt und die Benutzeroberfläche vor dem Einchecken überprüft hätten, hätten Sie das Problem bemerkt?