6 Tage, um eine Zeile Code zu ändern (2015)

• Die Fabrik wird zu weniger als 10 % ausgelastet.
• Die Unternehmensrichtlinie begrenzt die Erstellung eines Backlogs von mehr als 3 Monaten.
• Wenn die Richtlinie auf 4 Monate geändert wird, ist das Problem gelöst.
• Eine Konfigurationsänderung in Legacy-Software erfordert die Änderung einer einzigen Codezeile.
• Der Prozess zur Umsetzung der Änderung umfasst das Einreichen eines Tickets, das Ausfüllen der erforderlichen Abschnitte und die Genehmigung durch einen Direktor.
• Die Änderung ist dringend, um Entlassungen zu vermeiden.
• Der Programmierer ändert den Code erfolgreich, aber fest codierte Variablen und andere Fehler verursachen Probleme.
• Der Code benötigt ein Copy Review und Tests und kann erst danach in die Produktion überführt werden.
• Der Zugriff auf die erforderliche Testumgebung verzögert sich aufgrund von Berechtigungs- und Verfügbarkeitsproblemen.
• Parameterdatensätze müssen umbenannt werden und eine Audit-Trail erhalten.
• Der Programmierer führt die erforderlichen Änderungen durch und reicht den Code erneut zur Überprüfung ein.
• Für die Tests ist ein geeigneter Testplan erforderlich, einschließlich vom Benutzer ausgewählter Testfälle und erwarteter Ergebnisse.
• Nach 6 Tagen wird das Programm für die Überführung in die Produktion freigegeben.

[GN⁺]

Hacker-News-Kommentare

• Das zentrale Problem ist, Änderungen abzulehnen, wenn Reviewer Änderungen verlangen, die sich auf andere Teile der Codebasis auswirken.
• Eng fokussierte Pull Requests und Widerstand gegen Scope Creep sind wichtige Lehren.
• Der Code-Review-Prozess kann voller pingeliger Einwände und kleinlicher Kommentare sein.
• Das Sicherheitsteam reagiert möglicherweise nicht schnell auf Berechtigungsanfragen.
• Der Titel des Artikels kann irreführend sein, und in den 6 Tagen gab es zusätzliche Verbesserungen.
• Eine Änderung in nur einer Zeile kann unerwartete Folgen haben.
• Der Code-Review-Prozess kann zu einem Gatekeeper werden und den Fortschritt verzögern.
• Es ist effizienter für die Entwicklung, Commits nicht zu blockieren und stattdessen Kommentare zuzulassen.
• Von einem Team mit formalen Code Reviews zu einem ohne solche zu wechseln, kann erfrischend sein und mehr Eigenverantwortung ermöglichen.
• Es gibt Unterschiede darin, wie Fabrikarbeiter und Softwareentwickler geführt werden.
• Änderungen anhand wechselnder Teamideale zurückzuhalten, ist dysfunktional.
• Das Problem liegt im Prozess des Unternehmens, nicht im Code Review selbst.