Prawdziwy powód, dla którego Twoje PR-y są tak duże
Pracowałem kiedyś w firmie, która z przyzwyczajenia wysyłała ogromne pull requesty. Jeden PR mógł pozostawać otwarty przez tygodnie. Jego recenzja wymagała trzymania w głowie całego podsystemu. Błędy piętrzyły się. Terminy uciekały. W końcu musieliśmy przebudować dużą część systemu, ponieważ nikt nie był już w stanie bezpiecznie wprowadzać w nim zmian.
Inżynierowie nie byli źli. Byli inteligentni i ciężko pracowali. PR-y rosły z nudnego powodu.
Nikt nie nauczył ich, jak dzielić pracę na mniejsze części.
Często traktujemy duże PR-y jako problem z dyscypliną. Mówimy: „Po prostu twórz mniejsze PR-y”. Zachowujemy się, jakby jedyną różnicą między 1500 zmianami a 150 zmianami była siła woli.
To nie kwestia siły woli. Dzielenie dużej pracy na małe, niezależne fragmenty to umiejętność. Większość ludzi nigdy się jej nie nauczyła. Gdy ticket mówi „dodaj płatności”, wydaje się to jednym zadaniem. Najtrudniejsze jest dostrzeżenie, gdzie kończy się jeden PR, a zaczyna kolejny.
Ja też kiedyś wysyłałem duże PR-y. Myślałem, że „gotowe” oznacza rozwiązanie całego problemu naraz i wysłanie go do recenzji. Nauka tego, że mniejsze jest lepsze, zajęła mi lata.
Małe PR-y zmieniły dla mnie wszystko:
- Recenzenci wyłapują więcej błędów. Człowiek jest w stanie przeanalizować 200 zmian. Nie jest w stanie przeanalizować 2000. Po prostu je przeglądają i zatwierdzają.
- Merge'owanie następuje szybciej. PR-y przestają zalegać w kolejce.
- Przestałem czuć się przytłoczony. Skupiałem się na jednym elemencie naraz.
- Stałem się lepszym planistą. Musisz rozumieć strukturę swojej pracy, aby móc ją podzielić.
Zacząłem postrzegać systemy jako klocki Lego. To małe elementy, które łączą się ze sobą. Gdy zaczniesz widzieć te klocki, dzielenie pracy staje się naturalne.
Mój obecny zespół wysyła małe PR-y. Rezultaty są jasne:
- Nasz średni czas merge'owania to 1,5 dnia.
- Szybko znajdujemy i naprawiamy błędy, ponieważ zmiany są czytelne.
- Nasze terminy dostarczania są przewidywalne.
Dzielenie pracy to umiejętność, której trzeba uczyć. Nie naprawisz dużych PR-ów za pomocą zasady. Naprawisz je, ucząc ludzi dostrzegania klocków.
AI sprawia, że ta umiejętność staje się jeszcze ważniejsza.
W przeszłości napisanie 2000 linii kodu wymagało dużego wysiłku. To tarcie sprawiało, że PR-y były mniejsze. AI usunęło to tarcie. Możesz wygenerować ogromne zmiany za pomocą jednego promptu.
Wysiłek nie zniknął. Przeniósł się po prostu na recenzenta. Autor nie ponosi żadnych kosztów, ale recenzent płaci pełną cenę.
Jeśli rozmiar nie sygnalizuje już, ile pracy włożył autor, to niewiele mówi ci on o ryzyku. Musisz zdecydować, które fragmenty zasługują na twoją najstaranniejszą uwagę.
Naucz swój zespół dostrzegać cegły. To nawyk o największej dźwigni w inżynierii.
Jak twój zespół decyduje, które PR-y wymagają głębokiego przeglądu, a które mogą przejść szybko?
Źródło: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi