Co jest przydatnym sposobem myślenia podczas przeprowadzania formalnej weryfikacji kodu

14

Nasz zespół niedawno zaczął przeprowadzać przeglądy kodu przy każdym zameldowaniu.

Jako przewodniczący zespołu staram się znaleźć równowagę między dostarczaniem zbyt wielu sugestii, denerwowaniem programistów i zmniejszaniem wydajności zespołów, a puszczaniem kodu, napisałbym inaczej.

Czy są jakieś dowody, badania lub wskazówki z dobrze znanych źródeł, które sugerują pomocne podejście?

Kye
źródło
2
Pierwsze pytanie, które sobie zadajesz: dlaczego przeprowadzasz recenzje kodu?
Philip Kendall
1
Kusiłoby mnie, aby przypisać jakąś „wagę” każdemu zwrotowi. Krytyczna luka w zabezpieczeniach = bardzo duże znaczenie. Błąd = normalne znaczenie. Formatowanie kodu = zero znaczenia (obwiniaj narzędzia, które nie formatują automatycznie w dowolny sposób, a nie programista).
Brendan
To może Cię zainteresować
Laiv
Sposób, w jaki dana osoba podchodzi do recenzji kodu lub reaguje na nią, mówi wiele o jej zdolności do zachowania obiektywności i krytycznego myślenia. Czasami programiści potrzebują specjalnie do tego celu szkolenia.
Frank Hileman

Odpowiedzi:

15

Pamiętaj o nadrzędnych celach: w końcu liczy się tylko działające oprogramowanie

Recenzja kodu i kod odprawy mają na celu poprawę jakości . Ale nie ma nic gorszego pod względem jakości niż zdemotywowany programista. Jako lider zespołu, Twoim zadaniem nie jest popieranie kodu jako czegoś, co sam mógłbyś napisać, ale promowanie pracy zespołowej i zapewnienie ogólnego wyniku.

Określ jasny zakres swojej recenzji

Pamiętaj: to nie jest twój kod, ale kod zespołu. Dlatego skup się na rzeczach, które mogą prowadzić do błędnych wyników.

  • Nie kwestionuj sposobu, w jaki programista wybrał spełnienie wymagań, chyba że masz pewność, że to nie zadziała (ale nie powinno już przejść testów, prawda?)

  • Nie kwestionuj niskiej wydajności, chyba że istnieje miara pokazująca, gdzie jest problem. Przedwczesna optymalizacja jest źródłem wszelkiego zła ;-)

  • Jeśli znajdziesz projekt lub strukturę oprogramowania do zakwestionowania, zadaj sobie pytanie, dlaczego nie został on złapany z góry! Pisanie już napisanego kodu jest drogie. Jeśli tak się stanie, nadszedł czas, aby przejrzeć praktyki w zakresie tworzenia oprogramowania i pracy zespołowej co najmniej tak samo jak kod.

  • dotyczyć zgodności z ustalonymi standardami kodowania. To najbardziej denerwujący temat do omówienia zarówno dla recenzenta, jak i recenzowanego. Kiedy wszyscy zgodzili się używać wielkich nazw klas w twoim zespole, a jeden facet ma klasę bez, czy to kwestia gustu? A może skuteczność pracy zespołowej i ryzyko?

Nawiasem mówiąc, jeśli uważasz, że standard kodowania nie jest wart dyskusji, usuń go ze swoich standardów i nie marnuj na niego czasu ani energii.

Rozwijaj przywództwo: ludzka strona przeglądu

Jako lider zespołu możesz znaleźć tutaj okazję do rozwoju siebie i swojego zespołu, wykraczającego poza formalną kontrolę jakości:

  • Recenzje kodu są znacznie przyjemniejsze dla wszystkich, jeśli istnieje prawdziwa wymiana. Daj programistom również możliwość pokazania swoich umiejętności (i tak, być może możesz nauczyć się czegoś nowego).
  • Miej otwarte ucho na krytykę wyborów projektowych lub istniejących standardów. Czasami ludzie lepiej radzą sobie z takimi frustracjami, tylko dlatego, że mogą o tym rozmawiać.
  • Wytrenuj swoich juniorów: nie wahaj się udzielać porad lub zmieniać zasad dla następnej iteracji. Nie rób tego z seniorami: w innym świecie Twoja rola mogła się zmienić.

Skorzystaj z innych praktyk

Podczas przeglądu kodu można uniknąć kilku rzeczy:

  • Zastosowanie statycznego analizatora kodu w łańcuchu kompilacji może zautomatyzować wyszukiwanie typowych błędów lub konstrukcji nieprzenośnych na długo przed recenzją. Niektóre narzędzia mogą nawet sprawdzić niektóre standardy kodowania .
  • Jeśli masz standardy dotyczące układu kodu, użyj formatek drukowanych z wyprzedzeniem lub podobnych formatów, aby sformatować kod zgodnie z wymaganiami automatycznie. Nigdy nie marnuj czasu na coś, co oprogramowanie może dla Ciebie zrobić lepiej i bez dyskusji :-)
  • Wreszcie jakość zapewnia nie tylko przegląd, ale także testy. Jeśli jeszcze nie korzystasz z TDD , pomyśl o tym niezależnie od recenzji kodu.
Christophe
źródło
„Działające oprogramowanie”? Niezbyt przydatne. „Prawidłowe oprogramowanie” - to właśnie wolę!
Frank Hileman
@FrankHileman Rzeczywiście! I dokładne, niezawodne, użyteczne, wydajne i dostosowane do celu. To tylko kwestia odpowiedniego zdefiniowania terminu „działający” ;-)
Christophe
3

Jako programiści powinniśmy być zawsze otwarci i jednocześnie sceptyczni.

Otwarte, ponieważ nie wiemy, kiedy programista może nas zaskoczyć, i sceptycznie podchodzimy do naszych własnych pomysłów, ponieważ często zapominamy, że w inżynierii oprogramowania nie ma jednego poprawnego sposobu wdrożenia rozwiązania. Racjonalne uzasadnienie naszych rozwiązań może mieć dla nas sens i nie mieć żadnego dla innych. Za zapachem kodu może być świetny pomysł. Być może programista nie znalazł sposobu, aby wyrazić to poprawnie.

Ponieważ my (ludzie) jesteśmy okropni w komunikacji, nie róbmy fałszywych założeń, chętnie zapytaj właściciela kodu o kod, który przeglądasz. Jeśli nie uda mu się zakodować pomysłu zgodnie ze standardami firmy, jako główny deweloper chętnie też go poprowadzi.

Tutaj podejście subiektywne. Podejście obiektywne, IMO, jest bardzo dobrze wyjaśnione w tym pytaniu .

Oprócz powyższego łącza zestaw celów do osiągnięcia (łatwość utrzymania, czytelność, przenośność, wysoka spójność, luźne połączenie itp.) Niekoniecznie jest Dziesięcioma Przykazaniami. Ty (zespół) powinieneś być w stanie dostosować te cele do punktu, w którym równowaga między jakością a produktywnością sprawia, że ​​praca jest wygodna i „nadaje się dla deweloperów”.

Sugerowałbym użycie narzędzi do analizy kodu statycznego do pomiaru postępu jakości zgodnie z tymi celami. Narzędzia takie jak SonarQube zapewniają nam bramki jakości i profile jakości, które można dostosowywać zgodnie z naszymi priorytetami. Zapewnia nam także narzędzie do śledzenia problemów, w którym programiści mogą być ukierunkowani na problemy związane z zapachem kodu, błędami, wątpliwymi praktykami itp.

Tego rodzaju narzędzia mogą być dobrym punktem wyjścia, ale, jak powiedziałem, bądź sceptyczny. Niektóre zasady w Sonar mogą być dla Ciebie bez znaczenia, więc możesz je zignorować lub usunąć z profilu jakości.

Laiv
źródło
2

Wtrącanie się w kod dewelopera dotyczący zmian kosmetycznych zdemotywuje programistę, ale w absolutnych okolicznościach należy to zrobić. Prowadzący musi znaleźć równowagę między zapewnieniem przydatnego przeglądu kodu a nauczeniem się eliminowania drobnych niedociągnięć. https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

Nishanth Menon
źródło
jakie są „absolutne okoliczności” wymagające zmian kosmetycznych?
Ewan
1
W przypadku nieprzestrzegania wytycznych dotyczących kodowania, wady projektu kodu, które mogą powodować wycieki pamięci, to przypadki, w których lead nie może pozwolić sobie na zwolnienie.
Nishanth Menon
Twój link nie działa
Greenonline,
1

Kilka rzeczy, o których należy pamiętać:

  1. Dotyczy to zarówno psychologii, jak i technologii, więc nie ma tutaj złotej reguły.
  2. W ludziach chodzi nie tylko o wiedzę, ale także o kulturę i pozycję w hierarchii.
  3. Jeśli jest to „długa” gra (stabilna i ugruntowana firma), dobrze zintegrowany zespół, w którym ludzie sobie ufają, ma zwykle większą wartość niż testowany kod. Nie należy go używać do wymuszania rzeczy, które nie są absolutnie wymagane do kontynuowania. Diabeł tkwi w szczegółach ...
  4. Jeśli jest to „krótka” gra (poboczny projekt, prace badawczo-rozwojowe, wielu freelancerów w grupie), koszty CR często pokonują korzyści wynikające z ich zrobienia. I postawa powinna brzmieć „po prostu zrób to wok”
smentek
źródło
-4

Ważne są tylko dwie rzeczy.

  1. Czy istnieją zautomatyzowane testy dla wszystkich wymagań?
  2. Czy wszyscy przechodzą?

Wszystko inne jest kosmetyczne i powinno się o nie kłócić się o piwo, a nie egzekwować je jako bramę.

Jeśli zastosujesz się do tego widoku, ograniczy on Cię do wąskiego obszaru ostrości.

Czy wymagania są dobre? To, co najlepiej wiedzieć przed rozpoczęciem zadania, tj. Wydajność, bezpieczeństwo itp., Powinny tam być

Czy testy są dobre? Jakieś przypadki pominięcia krawędzi, czy dobrze testują wymaganie itp. Ostatecznie: Czy możesz napisać test, który dotyczy istniejącego wymagania, ale który zawiedzie?

Ewan
źródło
3
Czy powiedziałbyś, że kod bez żadnych podziałów linii, z nazwami zmiennych zawierających tylko jedną literę i w inny sposób zaciemniony jest dopuszczalny? Wszystkie testy przeszłyby pomyślnie, ale nie jest to możliwe do utrzymania .
Philip Kendall
W przeglądzie kodu? tak. Jak tylko zaczniesz nazywać to wszystko subiektywnie. Wybrałeś skrajny przykład, ale istnieje wiele przypadków, w których ludzie używają iteratorów jednoliterowych lub zagęszczają kod w funkcjach jednowierszowych, co byłoby uważane za dobrą praktykę
Ewan