Unikanie rozszerzania zakresu projektu

„Rozszerzenie zakresu” ma miejsce, gdy lista problemów rozwiązanych lub funkcji wdrożonych w ramach jednego wkładu znacznie wykracza poza to, co było zamierzone na początku pracy. Zaczynasz od prostego problemu, odkrywasz ściśle powiązany problem i decydujesz się uwzględnić również to rozwiązanie, a potem pojawia się trzeci… Zanim się zorientujesz, masz pull request, który zamyka 5 problemów i dodaje 3 nowe funkcje, w tym dziesiątki plików.

Rozszerzanie zakresu projektu zdarza się każdemu. Jest to pojęcie dobrze znane doświadczonym programistom; wszyscy robiliśmy to wielokrotnie i doświadczyliśmy wszystkich problemów, które się z tym wiążą.

Istnieją bardzo praktyczne powody, dla których należy unikać rozszerzania zakresu projektu. Im większy jest wkład, tym trudniej jest nad nim pracować. Trudniej jest zidentyfikować skrajne przypadki lub potencjalne problemy, co oznacza, że ogólna jakość wkładu może ulec pogorszeniu. Recenzje stają się również trudniejsze, gdy recenzent musi zajmować się wieloma, potencjalnie niepowiązanymi kontekstami. Większy wkład oznacza więcej komentarzy recenzentów, a jako autor wkładu może być trudno śledzić wiele wątków recenzji. Nawet Twoje doświadczenia z GitHubem ucierpią — interfejs użytkownika GitHub spowolni wraz ze wzrostem rozmiaru PR, co oznacza, że nawigacja po plikach za pośrednictwem interfejsu GitHub i próba pozostawienia komentarzy recenzentów stanie się coraz trudniejsza.

Za każdym razem, gdy znajdziesz powód, aby dodać coś do swojego wkładu, co nie jest wyraźnie częścią pierwotnej propozycji lub zgłoszenia błędu, powinieneś rozważyć, czy nie zmierzasz w kierunku rozszerzenia zakresu projektu. Czy istnieją dwie odrębne funkcje, które można by wdrożyć osobno? Czy funkcja może zostać wdrożona ze znanym ograniczeniem lub błędem, a błąd ten naprawiony w kolejnym pull request? Czy jedna część poprawki błędu jest niezależna od drugiej? Jeśli część zmiany można pominąć bez zmiany pierwotnego wkładu, prawdopodobnie należy to zrobić.

Tworzenie oprogramowania to zawsze proces stopniowego doskonalenia. Każdy indywidualny wkład powinien poprawiać stan kodu źródłowego w wyniku scalenia, ale całkowicie dopuszczalne jest pozostawienie błędów lub części funkcji do poprawienia w przyszłości. Może to oznaczać podzielenie pull requestu na wiele części, które można sprawdzić niezależnie, lub zarejestrowanie problemu, aby ktoś inny mógł go zbadać i rozwiązać.

Ograniczenie zakresu każdego wkładu pomaga wszystkim zaangażowanym osobom, w tym również Tobie. Twoi recenzenci, a nawet Ty sam, z pewnością to docenicie.