Vermeidung von Scope Creep

"Scope creep" passiert, wenn die Liste der gelösten Probleme oder implementierten Funktionen durch einen einzelnen Beitrag deutlich über das hinausgeht, was zu Beginn der Arbeit beabsichtigt war. Sie fangen mit einem einfachen Problem an; Sie entdecken ein eng verwandtes Problem und beschließen, auch diese Lösung einzubeziehen; dann ein drittes… bevor Sie es merken, haben Sie einen Pull Request, der 5 Probleme schließt und 3 neue Funktionen hinzufügt, einschließlich Dutzende von Dateien.

Scope Creep passiert jedem. Ein Konzept, das erfahrenen Entwicklern nur allzu vertraut ist. Wir alle haben es schon mehrfach erlebt und alle damit verbundenen Probleme erfahren.

Es gibt sehr praktische Gründe, eine Ausweitung des Umfangs zu vermeiden. Je größer ein Beitrag wird, desto schwieriger ist es, mit ihm zu arbeiten. Es wird schwieriger, Randfälle oder potenzielle Probleme zu erkennen, was bedeutet, dass die Qualität des Beitrags insgesamt gemindert werden kann. Auch die Überprüfung wird schwieriger, wenn sich der Prüfer mit mehreren, möglicherweise nicht zusammenhängenden Kontexten befassen muss. Ein größerer Beitrag bedeutet mehr Überprüfungskommentare, und als Mitwirkender kann es schwierig werden, mehreren Überprüfungssträngen zu folgen. Sogar Ihre GitHub-Erfahrung wird darunter leiden - die Benutzeroberfläche von GitHub wird mit zunehmender Größe eines PR langsamer, was bedeutet, dass die Navigation durch die Dateien auf der GitHub-Benutzeroberfläche und der Versuch, Überprüfungskommentare zu hinterlassen, immer schwieriger wird.

Jedes Mal, wenn Sie einen Grund finden, etwas zu Ihrem Beitrag hinzuzufügen, das nicht explizit Teil des ursprünglichen Vorschlags oder Fehlerberichts ist, sollten Sie überlegen, ob Sie sich auf eine Ausweitung des Umfangs zubewegen. Gibt es zwei verschiedene Funktionen, die separat implementiert werden könnten? Könnte eine Funktion mit einer bekannten Einschränkung oder einem Fehler implementiert werden, und dieser Fehler in einem nachfolgenden Pull Request behoben werden? Ist ein Teil einer Fehlerbehebung unabhängig von einem anderen? Wenn ein Teil einer Änderung weggelassen werden kann, ohne den ursprünglichen Beitrag zu verändern, sollte es wahrscheinlich sein.

Die Entwicklung von Software ist immer ein Prozess der schrittweisen Verbesserung. Jeder einzelne Beitrag sollte die Codebasis in einem besseren Zustand hinterlassen, aber es ist völlig akzeptabel, Fehler oder Teile von Funktionen als Arbeit für zukünftige Verbesserungen zu hinterlassen. Das kann bedeuten, dass man eine Anfrage in mehrere Teile aufteilt, die unabhängig voneinander überprüft werden können, oder dass man einen Fehler protokolliert, damit jemand anderes das Problem untersuchen und beheben kann.

Die Begrenzung des Umfangs der einzelnen Beiträge hilft allen Beteiligten, auch Ihnen. Ihre Prüfer und auch Sie selbst werden es zu schätzen wissen.