Problem w tym, że code review łatwo zamienia się w formalność: ktoś klika "Approve" po dziesięciu sekundach, albo przeciwnie - przegląd grzęźnie w niekończącej się dyskusji o wcięciach. Poniżej pokazuję, jak ustawić ten proces w projektach .NET tak, żeby realnie działał, oraz jaką rolę odgrywa w tym lider techniczny.
Ustalenie standardów kodowania – fundament udanego review
Zanim w ogóle zaczniemy przeglądać cudzy kod, zespół musi mówić jednym językiem. Spójne konwencje - nazewnictwo, formatowanie, struktura projektów - sprawiają, że kod każdej osoby wygląda podobnie. Dzięki temu recenzent skupia się na tym, co naprawdę ważne (logika, architektura, przypadki brzegowe), zamiast na drobnostkach stylistycznych.
W .NET nie trzeba tego wymyślać od zera. Warto oprzeć się na oficjalnych konwencjach C# od Microsoftu, a następnie zautomatyzować ich egzekwowanie, żeby styl w ogóle zniknął z dyskusji w PR-ach:
• .editorconfig - jeden plik w repozytorium, który opisuje reguły formatowania i nazewnictwa. Trzymany razem z kodem działa tak samo w Visual Studio, VS Code, Riderze i na CI.
• Analizatory Roslyn - wbudowane analizatory .NET (dostępne domyślnie od .NET 5) plus pakiety takie jak StyleCop.Analyzers czy SonarAnalyzer.CSharp wychwytują problemy już podczas pisania kodu, w IDE.
• dotnet format oraz TreatWarningsAsErrors - automatyczne formatowanie i traktowanie ostrzeżeń jak błędów sprawiają, że niezgodny ze standardem kod po prostu nie przejdzie buildu.
Zasada jest prosta: wszystko, co da się sprawdzić maszynowo, powinna sprawdzać maszyna. Człowiek jest zbyt cenny, żeby marnować jego uwagę na to, czy klamra jest w tej samej linii. Rola lidera technicznego jest tu kluczowa - to on pomaga zdefiniować te zasady i pilnuje, żeby weszły w krew całego zespołu.
Pull Requesty na GitHub / Azure DevOps - kręgosłup procesu
Nowoczesny code review w .NET opiera się na Pull Requestach. Zamiast zaglądać sobie przez ramię, tworzymy dedykowany PR na GitHubie lub w Azure DevOps, który gromadzi wszystkie zmiany w jednym miejscu i pozwala je łatwo porównać z bieżącym kodem.
Kilka praktyk, które robią największą różnicę:
• Dobry opis PR. Autor tłumaczy co i dlaczego się zmienia, a nie tylko jak. Kontekst ("naprawiam błąd X, dlatego dodaję walidację Y") oszczędza recenzentom mnóstwo czasu. Warto do tego przygotować szablon PR w repozytorium.
• Mały, skupiony zakres. Przegląd 100 linii to rozmowa, przegląd 2000 linii to przybijanie pieczątki. Mniejsze, częstsze PR-y są weryfikowane szybciej i dokładniej. Jeśli zmiana rozrasta się w trakcie pracy, lepiej podzielić ją na kilka mniejszych.
• Self-review przed wysłaniem. Autor powinien sam przejrzeć swój diff, zanim poprosi kogoś o ocenę. Połowa "uwag" znika, gdy spojrzymy na własny kod świeżym okiem.
• Automatyzacja przez CI. Każdy PR powinien automatycznie przechodzić kompilację, testy jednostkowe i analizę statyczną (GitHub Actions, Azure Pipelines, SonarQube). Recenzent od razu widzi zielony status, a jeśli coś jest czerwone, nie ma sensu w ogóle zaczynać przeglądu.
• Rzeczowa dyskusja w komentarzach. Komentujemy konkretne linie, zadajemy pytania, proponujemy alternatywy. Celem jest ulepszenie kodu, a nie udowodnienie komuś, że się pomylił.
Definiowanie kryteriów akceptacji
Żeby przeglądy były powtarzalne, warto z góry ustalić, co musi być spełnione, zanim kod trafi na główną gałąź. Taka lista kontrolna mówi recenzentom, na co patrzeć, a autorom - co sprawdzić przed wysłaniem PR-a.
Przykładowe kryteria:
• Zgodność ze standardami - kod trzyma się przyjętych konwencji stylu i nazewnictwa (a większość tego pilnuje już CI).
• Poprawność i kompletność - zmiana rozwiązuje zgłoszony problem lub realizuje wymaganie, działa poprawnie i nie psuje istniejących funkcjonalności.
• Testy i dokumentacja - dołączono testy jednostkowe/integracyjne pokrywające nowy kod, wszystkie przechodzą, a dokumentacja i istotne komentarze są aktualne.
• Jakość i czytelność - kod jest zrozumiały dla innych, logika jest sensownie rozbita na mniejsze metody, uwzględniono aspekty wydajności i bezpieczeństwa (brak nowych podatności, brak oczywistych regresji).
• Peer review i zatwierdzenie - przynajmniej jedna osoba przejrzała zmiany i je zaakceptowała, a wszystkie istotne uwagi zostały omówione i wdrożone. Dopiero wtedy robimy merge.
Taką listę najlepiej trzymać w szablonie PR lub na wiki projektu - wtedy nic ważnego nie umknie, nawet w gorętszy dzień.
Jak dawać feedback, którego nie boi się zespół
To część, którą najłatwiej zaniedbać, a często decyduje o tym, czy code review pomaga, czy dzieli zespół.
Kilka rzeczy, które warto wdrożyć:
• Oddzielaj "muszę" od "fajnie by było". Pomaga w tym konwencja komentarzy - prefiksy w stylu nit: (drobiazg, nieblokujące), pytanie:, sugestia:, blocker:. Autor od razu wie, co naprawdę wstrzymuje merge, a co jest tylko luźną uwagą.
• Krytykuj kod, nie człowieka. "Ta metoda robi 3 rzeczy naraz, może warto ją rozbić?" brzmi zupełnie inaczej niż "napisałeś to źle".
• Chwal dobre rozwiązania. Jedno "o, sprytnie to rozwiązałeś" potrafi zmotywować bardziej niż 10 poprawek.
• Reaguj szybko. PR wiszący 3 dni blokuje autora i psuje flow. Warto umówić się w zespole na rozsądny czas reakcji na przegląd.
Rola lidera technicznego w budowaniu kultury
Lider techniczny nadaje ton całemu procesowi - najlepiej własnym przykładem.
Kilka najważniejszych aspektów tej roli:
• Ustanawianie standardów i zasad. Tech Lead pomaga wdrożyć standardy kodowania oraz kryteria przeglądu i tłumaczy zespołowi, po co to robimy.
• Mentoring zamiast oceniania. Dobry lider traktuje review jako okazję do nauki - nie tylko wskazuje błąd, ale też podpowiada lepsze rozwiązanie i dzieli się doświadczeniem. Dla mniej doświadczonych osób takie wskazówki są bezcenne.
• Kultura feedbacku. To lider pilnuje, żeby krytyka dotyczyła kodu, a nie autora, a dobre rozwiązania były doceniane. Dzięki temu ludzie nie boją się pokazywać swojego kodu.
• Dyscyplina procesu. Często to na liderze spoczywa pilnowanie, żeby review nie stało się pomijaną formalnością - np. że nic nie trafia na main bez przeglądu, a krytyczne fragmenty wymagają 2 recenzentów.
Przy takim wsparciu code review przestaje być zwykłym filtrem błędów, a staje się narzędziem ciągłego podnoszenia poziomu zespołu.
Podsumowanie
Efektywny code review w .NET to inwestycja, która zwraca się w postaci lepszego kodu i bardziej zgranego, świadomego zespołu. Jasne standardy kodowania, dobre wykorzystanie Pull Requestów i automatyzacji, konkretne kryteria akceptacji oraz zdrowa kultura feedbacku - to elementy, które razem sprawiają, że problemy wyłapujemy, zanim zobaczy je użytkownik. A klucz do tego wszystkiego trzyma lider techniczny, który kształtuje przegląd kodu jako proces nastawiony na naukę i wspólne doskonalenie, a nie na krytykę.
Skoro dotarłeś aż tutaj, to znak, że traktujesz jakość kodu poważnie, a to dokładnie ta postawa, która na dłuższą metę robi różnicę w pracy z .NET. Jeśli chcesz regularnie dostawać konkretne wskazówki, dobre praktyki i rozwiązania realnych problemów z projektów .NET - takie, które od razu wykorzystasz w codziennej pracy - zapraszam Cię na moją listę VIP: modestprogrammer.pl/vip.
To miejsce, w którym dzielę się wiedzą prosto ze skrzynki - często bardziej praktyczną i "od kuchni" niż to, co trafia na bloga. Zero spamu, sama konkretna treść dla programistów, którym zależy na rozwoju. Do zobaczenia po drugiej stronie.
